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

John McCall via cfe-commits cfe-commits at lists.llvm.org
Mon Jul 8 11:35:06 PDT 2024


================
@@ -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);
----------------
rjmccall wrote:

I feel like we just need to file a DR with WG21 on this general question.  The alternatives I can see:

1. Forbid TLVs in coroutines. Source-breaking.
2. Continue to eagerly initialize local TLVs in coroutines, but bind the name permanently to the TLV that was initialized. This means it is potentially a cross-thread reference after a suspension. It is the user's responsibility to make that not a problem. A semantics change for most (if not at all) existing compilers.
3. Like #2, but give references to the TLV undefined behavior if the thread has changed. The most compatible option, sadly.
4. Like #2, but make the program statically ill-formed if a suspension potentially intervenes between the initialization and a reference to the TLV. Source-breaking. Also a significant new implementation burden for compilers.
5. Switch local TLVs in coroutines to the same lazy-initialization model as global TLVs.  Every reference to the variable dynamically resolves to the TLV for the current thread.  Because of the model change, the variable is always initialized. A semantics change for most (if not all) existing compilers.
6. Like #5, but require the initializer to be a constant expression just to try to minimize the semantic impact.

Note that a cross-thread reference can race not just with read/write or write/write conflicts between threads, but also with the destruction of the other thread.  Because of the latter, it will be a potentially-dangling reference for most async-like use cases.

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


More information about the cfe-commits mailing list