[mysterymath]

Up until just a few weeks ago, 100% of the codegen work we've put into LLVM-MOS has been to get it feature-complete and rock-solid. It's awesome to see that that work has paid off!

We're just now starting to really optimize the compiler; there's definitely a long road ahead of us, but our preliminary investigations suggest that we'll be able to get the thing to emit really quite good 6502 assembly.

Right now, it emits near-garbage in a large number of common cases, as seen in the article. This is mostly due to technical debt intentionally accrued while getting the thing working, though; we did stuff like use the default LLVM lowering for comparisons, which are ridiculously trash on the 6502. But there's only really a couple major technical hurdles left to overcome; everything else is just painstakingly teaching LLVM what the best 6502 assembly patterns are for various situations.

[zozbot234]

> We're just now starting to really optimize the compiler; there's definitely a long road ahead of us, but our preliminary investigations suggest that we'll be able to get the thing to emit really quite good 6502 assembly.

Is there any part of this optimization work that might be upstreamed to LLVM itself and benefit other architectures? Or is this stuff purely 6502-specific?

[mysterymath]

Some of it might benefit AVR, which being 8-bit, shares some of the same problem space. But most of the changes we've made so far are of the kind where LLVM says "this doesn't happen", or "when it does, it's not important." And now the 6502 says, "uh, I actually do need that..."

So in absolute terms of maximizing the flexibility of LLVM, yes, the changes do seem to be broadly useful, but they're mostly in a direction that doesn't benefit most processors all that much.

For example, the 6502 really wants to replace stack usage with global usage; we do this absolutely whenever possible. Other targets actually run the opposite transformation; they replace global variables with stack ones! Placing things on the stack maximizes the chance it'll be in a fast CPU cache (or that it may be folded into a register; this does apply to us too.)

[zozbot234]

> For example, the 6502 really wants to replace stack usage with global usage; we do this absolutely whenever possible.

If I understand what you're getting at, this transformation comes up all the time when compiling either coroutines or user-space "green" threads. More obviously, it could expand the usefulness of LLVM for targeting very low-end microcontrollers (even "modern" ones targeting varieties of ARM or other recent architectures) where stack space, and memory more generally is often at a premium.