Support TLS

[luismarques]

I've migrated a D codebase from the riscv/riscv-llvm -based compiler to the lowRISC/riscv-llvm one. After the latest lowRISC/riscv-llvm changes I was able to remove essentially all workarounds for invalid code (although the latest changes (because of the new branch analysis?) seemed to cause a 4X performance penalty, despite allowing more modules to compile without -O0).

The only major issue remaining for great D support in this LLVM backend is the lack of thread-local storage. Since D globals default to TLS, that lack is particularly felt. I'm opening this issue to communicate the relative importance of adding TLS. Please address that when possible.

[asb]

Hi Luis, great to hear you're having some success with D and LLVM. The performance issue is due to a temporary regression in stack frame handling (stack frames are always created) which I hope to come back and resolve shortly. TLS is a high priority for me too, as it's obviously vital for running "real" programs.

I'll be posting a larger status update on the mailing lists on Monday, but to just give a quick overview of my approach.

1. Ensure (to the extent possible) that correct code always generated for a simple RV32I baseline
2. Expand that baseline for more RISC-V ISA variants (RV{32,64}IMA, and later FD)
3. Push forwards on code quality and feature support. These go hand-in-hand to an extent, as we need to move to using larger-scale test programs to be more confident about the correctness of generated code.

We're currently well in to 2), and I expect we'll move on to 3) in the course of next week. Many thanks for kicking the tires, I'm looking forwards to usable RISC-V D support via LLVM (did anyone demonstrate D for RISC-V via GDC already?).

[luismarques]

Back in the time I was using the riscv/riscv-llvm repo, I managed to compile GDC with the RISC-V GCC backend, but I was disappointed with the results. With the old LLVM backend I wasn't generating machine code directly, because the compiler complained that wasn't supported (although that might have been my fault, the same happened with this new backend when I used -mtriple=riscv-linux-elf instead of -mtriple=riscv-unknown-elf in LDC, IIRC). So I was optimizing the code at the LLVM bitcode level (a mix of -O3, -O1 and -O0, due to bugs), but generating unoptimized RISC-V assembly (-O0, I think), which I then assembled with GCC. So I had good whole program optimizations but lousy local code (like jumping to what would be the next instruction anyway). So I thought that when I used the much better GCC backend with GDC things would improve immensely. But when I did finally manage to get a working RISC-V-based GDC compiler working, I found out that my program actually ran slower...

I tried a few days ago to checkout again GDC, but I didn't manage to compile it with the RISC-V GCC backend (on macOS), so I don't know how it currently compares. I think the conclusion is that the whole program optimizations mattered more than the peephole ones. Probably a cascade of optimizations due to better inlining...

I'm really looking forward to TLS. Even basic TLS support would allow me to start porting the D runtime and standard libraries. I might even stream that effort!

[luismarques]

BTW, FWIW nothing broke for me with the latest changes (75c94b1), even when using RV32IM.

[luismarques]

@asb Any progress towards TLS support?