On x86_64 Linux, $ cat tls.ll @external_tls_var = external thread_local(initialexec) global i32 define i32 @main() { store i32 6, i32* @external_tls_var ret i32 0 } $ ./bin/lli tls.ll LLVM ERROR: Cannot select: 0x2bac360: i64 = X86ISD::WrapperRIP 0x2bac258 [ORD=2] [ID=9] 0x2bac258: i64 = TargetGlobalTLSAddress<i32* @external_tls_var> 0 [TF=10] [ORD=2] [ID=7] In function: main
We're maintaining a branch that fixes this for x86_64 Linux only: https://github.com/JuliaLang/llvm/commit/a9e17b7f47f5afa9683fc8cfeff7020b2ff4a8b2 In general, to fix this properly, we'd need to add support for every C runtime library out there. In practice this probably isn't that bad because the layout of TLS is ABI defined and the compiler may need to know about it anyway.
I'm adding myself to the people who'd like to see this problem fixed.
Were there any updates regarding this bug? Soon it will be 5 years old, time to prepare the birthday cake.
Lack of TLS support means you can't use std::async() in Cling, for example. I'd really like to see this feature added.
Are you guys seeing *a* TLS failure, or this specific TLS isel failure? I wasn’t able to reproduce this using llc on Darwin (prodding the triple/code-model/reloc-model to try to match Linux JITing), but can try firing up a Linux VM if this particular bug still reproduces on Linux. If the problem is a lack of TLS support in general: That’s a known issue. We’ve been working around it with emulated TLS in some use cases, but it’s not well tested and I can imagine it falls over in a lot of places. I have a vague plan for how to support native TLS on Darwin, and I expect any code I add to the generic ORC APIs to support that will help with Linux TLS support too, but I will still need an ELF expert to step up when it comes to the actual ELF TLS implementation.