Interesting post, thanks. It certainly seems like llvm-mos' codegen is improving markedly modulo some concerns brought up over bloat. But I also note that a number of the performance recommendations (prefer using more globals, avoid passing structures presumably due to the limited hardware stack) aren't exactly current programming convention - and for that matter, they're exactly what you would do writing assembly by hand. These recommendations would be true for cc65 too of course, but it still makes the point that using C to develop on 6502 is just making the dog walk, not the dog walking well.

see also https://llvm-mos.org/wiki/Rationale

"As for the code itself, we perform a remarkably effective loop optimization that detects 16-bit index operations that can be converted to a 16-bit index plus an 8-bit offset. The latter is a directly-supported addressing mode on the 6502, and 8-bit index manipulation can be done in a single instruction.

This allows us to convert idiomatic 16-bit "int c" loops into something much more suitable for the 6502. Eventually, we hope that optimizations of this kind will transform standard, naive C code into tightly optimized 6502 code. "

I mean, I think it suffers the same problem as lisp on that front. If you're coming into a codebase would you rather read boring C or try to figure out the mind of the person who crafted the lisp/macros in it?

Even C codebases can suffer this with obnoxiously clever macros, but it's rarer at least.