I see jacobly0’s project uses the new GlobalISel framework, that’s nice, it makes it future-proof and is something I was missing from older LLVM Z80 backend attempts.
Thanks! Checking this files I confirmed that it uses the stack to pass arguments, expanding 8 bit parameters to 16 bit.
I used this knowledge to manually convert the assembler generated for the Sieve benchmark by the llvm-z80 to the sdcc calling convention, add the required extra libraries, and benchmark it.
When using the __smulu call:
CLANG frontend + LLVM-Z80 backend:
Delay: 367 ms
Size: 260 bytes ( not including the size of the __smulu function)
When inlining the "n*3" manually:
CLANG frontend + LLVM-Z80 backend:
Delay: 320 ms
Size: 261 bytes
As a reference, for the same function:
SDCC:
Delay: 324 ms
Size: 210 bytes
CLANG as front end + SDCC as back end:
Delay: 287 ms
Size: 196 bytes
I don't really see a lot of potential to improve the code generation performance of the llvm-z80 backend without a significant overhaul of the current code, and given the current issues, I don't find it worth the effort to migrate from the sdcc backend for the moment.
But it sucks missing the ability to pass structs by value, and the super long compilation times of SDCC are also a pity.
I also looked a bit into this. The changes from Jacob cover only llvm and clang, but neither the assembler nor the linker. Even though is quite an achievement to generate z80 code, without assembler or linker the outcome is a bit limited. There is not relocatable binary output, no elf files, and no linking as part of llvm for (e)z80.
To solve this he put together an assembler and linker using fasmg, in just 3k lines of configuration code. I haven't gone through it in detail yet, the assembler can be switched to z80 easily by swapping the configuration, but the linker is more difficult and is probably targeted at eZ80 and TI devices.
Interesting, I did have the assembler and linker working iirc (ended in the middle of code generation), though only for Z80 of course and I’m not very familiar with eZ80 (probably it makes things more complicated). Maybe I can find some time to dig up the code and see if our approach was similar and whether I’m able to merge it.
