This is intended to fix the TLS problem in coroutine described in https://github.com/llvm/llvm-project/issues/47179
Simply, we would assume the address of a TLS variable is same in one function. Since a function should be executed in one thread only. However, it is not true for unlowered coroutine. This patch tries to fix the problem by adding a wrapper for every TLS variable to block the alias analysis. Note that we couldn't do this for unlowered coroutine only due to inlining. Also the compiler is still available to optimize TLS variables for lowered coroutine.
I guess this is unnecessary under OpenMP because the privatization logic will already anchor this appropriately in the function. That's worth mentioning in a comment so that readers don't think the combination is somehow busted.
Same question as the other patch: is there any way to safely only do this in code that's actually going to be part of a coroutine? Because getLangOpts().Coroutines is true for everyone using -std=c++20, and most of that code is probably not using coroutines. It seems like we have two options:
I think the second option makes more sense. In the first option, the mere possibility of having coroutines in the module could significantly impede optimization. The second option also means you'll have to find and remove this pattern in *all* functions, not just when transforming coroutines.
You could also use the second option for your readnone problem: you can have your early pass make readnone calls directly from coroutine bodies coro_readnone instead, and the inliner can do the same for readnone calls being inlined into unsplit coroutines.