[PATCH] D125291: Introduce @llvm.threadlocal.address intrinsic to access TLS variable

[Chuanqi Xu via Phabricator via cfe-commits]

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