[llvm] [RISCV] Declare TLSDESC clobbers for vector registers and CSRs per psABI (PR #205027)

[Paul Kirth via llvm-commits]

ilovepi wrote:

> > Overall, this patch looks like its in good shape, and aligns with what's in the RISC-V psABI. I do have one concern, which I've raised in-line that I think we may want to discuss further w/ the psABI and external communities. I don't see this concern as blocking, though I'd like to get at least a bit of alignment on the issue or clarification so that we can either bring these up w/ the psABI w/ concrete ideas or document why we don't see this as a problem.
> 
> Thanks @ilovepi for raising this! And yes if so, I agree that it's worth discussing. In my humble opinion, as Kito also mentioned in psABI#496, one reason maybe that TLS code usually does not happen in V-code, so the downside maybe not so drastic. While yes, I guess we may need opinion from more experts :)
> 

I mean the optimizer is free to do whatever it wants right? LLVM is notorious for using vector regs and instructions whenever possible, but maybe this is not a problem in practice? This type question are what I think we should be discussing, since it seems like Aarch64 isn't harmed here.

 The end goal for me is not to block this patch, but to determine something concrete I can bring back to the psABI and say: "hey I think we overlooked something, maybe we can handle it better by...". There's no guarantee that would happen in a reasonable time frame, and hence why I don't want to block anything. 

> For now, May I ask what do you suggest we should do to this patch, add an option to disable V-clobbering or leave a TODO there, or wait till psABI discussion is all settled?
> 

I think the patch is fine, and I don't want to block progress on it, since I think getting alignment here w/ the psABI as its written right now is the right thing to do.  I think the thing that we want to do here is ask ourselves if we want something different if we know the libc guarantees a different property. Implementation wise, in LLVM, its probably 1 if condition to also do the base/default TLSDESC if you're musl/Fuchsia and ignore V regs altogether. I'm not advocating that right now, since I think we want to bring any discussion/conclusions to the psABI and get alignment across the community w.r.t. how we handle this.

> BTW I'm not quite familiar with Musl or Fuchsia, may I ask why don't they need the slow path? In my understanding, Musl has `dlopen` thus it needs dynamic TLS blocks, so I'm curious how it's got handled without the slow path (does it implement a "fully-inlined" `tls_get_addr` in tlsdesc handler? that may be quite complicated I guess). Please correct me if I've misunderstood anything.

This bit of the implementation isn't the part of the system I deal with the most, so there may be a few details I'm not conveying with 100% fidelity (especially about Musl) and you should take the following with a grain of salt. But its my understanding that, both Musl and Fuchsia's dynamic linkers rely on some rather magical syscall (`SYS_membarrier` on Linux and Fuchsia has an equivalent) to ensure that when they update the internal data structures at `dlopen` time, all other threads are synchronized with that event correctly. They both populate the TLS data structures, like the DTV, eagerly instead of lazily, and hence don't need a slow path at all, since every thread is synchronized on the change in TLS state. IIRC `Musl` doesn't support `dlclose` and right now neither does Fuchsia, though it will and we already have a prototype that works with the same mechanism.

As a result Fuchsia's new dynamic linker only requires I think 3 registers to support TLSDESC accesses, and never hits the slow path. Hence why I think it would be sad if we had to emit spills in V code for any TLS access, as on Fuchsia TLSDESC is the only form of supported TLS on any architecture.

For completeness Fuchsia is in the process of migrating to this new implementation, so there is still a legacy version in our tree that does the slow path fallback (with all the V regs getting saved and full DWARF CFI for all the variable length spills), but that migration will be done by Q3  (mid-Q4 at the latest), and we already use the new version in about half our components.

https://github.com/llvm/llvm-project/pull/205027