[PATCH] D143708: [RISCV] Add emulated TLS supported

Alex Bradbury via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 10 08:23:40 PST 2023


asb added a comment.

I left a few comments in D143619 <https://reviews.llvm.org/D143619> about the history of this discussion. Thanks for the clear summary of scenarios where this is needed and an example where someone is already carrying a downstream patch.

>From the discussion so far:

- In #59500 <https://github.com/llvm/llvm-project/issues/59500>, @kito-cheng raised the point that in theory emulated TLS shouldn't be necessary
- In #59500 <https://github.com/llvm/llvm-project/issues/59500>, @jrtc27 stated "Up until now it’s been a deliberate decision to not support emulated TLS, it’s terrible for performance and adds toolchain complexity."
- In D102527 <https://reviews.llvm.org/D102527>, @MaskRay expressed the hope that emutls could be removed from LLVM and that OpenBSD could stop relying on it, and @brad also hoped the OpenBSD developers could do this

So, what's changed / what new arguments have been raised since then?

- Partly nothing - it seems there's no movement on OpenBSD removing emutls support, and it seems OpenBSD are now carrying a patch downstream to enable it. On the plus side, that at least implies additional confirmation that this patch meets their requirements.
- @vit9696 has another use case that needs this "We make private use of generic emutls abi on one of our targets for portability and easier certification reasons."
- It was pointed out that rather than just not supporting emulated TLS, we're accepting the flag and generating incorrect code. So _something_ needs to be done.
- @vit9696 points out -femulated-tls would give parity with GCC. That's normally a compelling argument, though if LLVM were on the verge of removing emulated TLS for all targets it would be less compelling. As there's been no movement on this, perhaps it's not likely to happen any time soon?

In light of all of the above, what are your views @jrtc27, @maskray, @kito-cheng? I'll also note we have the regular RISC-V LLVM contributor call next Thu @ 4pm GMT. It may be we can resolve this discussion on this thread, but if not, that call might be a good venue for further discussion.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143708/new/

https://reviews.llvm.org/D143708



More information about the llvm-commits mailing list