[clang] [Clang] Access tls_guard via llvm.threadlocal.address (PR #96633)

[via cfe-commits]

================
@@ -1070,13 +1084,20 @@ CodeGenFunction::GenerateCXXGlobalInitFunc(llvm::Function *Fn,
       // Mark as initialized before initializing anything else. If the
       // initializers use previously-initialized thread_local vars, that's
       // probably supposed to be OK, but the standard doesn't say.
-      Builder.CreateStore(llvm::ConstantInt::get(GuardVal->getType(),1), Guard);
-
-      // The guard variable can't ever change again.
+      // Get the thread-local address via intrinsic.
+      if (IsTLS)
+        GuardAddr = GuardAddr.withPointer(
+            Builder.CreateThreadLocalAddress(Guard.getPointer()),
+            NotKnownNonNull);
+      Builder.CreateStore(llvm::ConstantInt::get(GuardVal->getType(), 1),
+                          GuardAddr);
+
+      // Emit invariant start for TLS guard address.
       EmitInvariantStart(
           Guard.getPointer(),
           CharUnits::fromQuantity(
-              CGM.getDataLayout().getTypeAllocSize(GuardVal->getType())));
+              CGM.getDataLayout().getTypeAllocSize(GuardVal->getType())),
+          IsTLS);
----------------
nikola-tesic-ns wrote:

I had similar concerns. IIUC, the safe(st possible) bet is to generate `threadlocal.address` at each access. In the view of this PR:
1. for the load of `tls_guard`
2. for the store into `tls_guard`
3. for the `invariant.start` intrinsic for `tls_guard`

I am not sure if there is a case where coroutine context switch could happen between `threadlocal.address` and its user instruction. If that is the case, then there is no guarantee for other use cases of `threadlocal.address` as well.
Do you agree or I am missing something?

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