ChuanqiXu added a comment. In D125291#3581064 <https://reviews.llvm.org/D125291#3581064>, @nikic wrote:
> In D125291#3548671 <https://reviews.llvm.org/D125291#3548671>, @jyknight > wrote: > >> Anyhow -- I think the prototype I'm fiddling with is also along the path to >> the ideal long-term state, but pushing it beyond a prototype seems like >> it'll be a pain in the ass due to the bitcode compatibility requirement. >> (The bitcode upgrader would need to know how to transform all constant >> expressions using a TLS global into non-constant IR instructions, starting >> with a call to llvm.threadlocal.address -- in every function where the >> "constant" is referenced. For uses outside a function body, it transforms to >> an arbitrary address (e.g. null), instead.) > > I have implemented support for converting constant expressions to > instructions in the bitcode reader in https://reviews.llvm.org/D127729. This > was originally intended for constant expression removal, but I think with > that infrastructure in place, upgrading TLS global references to use an > intrinsic would be fairly simple. Oh, it looks great! Especially in `getValueForInitializer`, we could solve the motivation problem given by @jyknight : @x = thread_local global i32 0, align 4 @y = global i32* @x, align 8 Now we are possible to emit proper diagnostic message. The only issue is that the current framework of D127729 <https://reviews.llvm.org/D127729> would map a constexpr into an instruction. But we might need to map a constexpr with TLS variables to multiple instructions (containing @llvm.threadaddress() intrinsics). But I believe this problem might be minor. @jyknight How do you think about the status quo now? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125291/new/ https://reviews.llvm.org/D125291 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
