================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
