[llvm] [llubi] Experimental support for noalias (PR #195808)

[Johannes Hostert via llvm-commits]

JoJoDeveloping wrote:

> the resulting transition is idempotent.

This is wrong. Consider the case where there are two threads, both of which operate on the same pointer. They now do this:

1. Thread A invokes a noalias function
2. Thread A writes to the pointer
3. Thread A synchronizes-with Thread B (via some other mechanism)
4. Thread B invokes a noalias function
5. Thread A's noalias function ends
6. Thread B writes to the pointer

This should have UB, because we want to allow the compiler to reorder the noalias access in thread A to a later point in time (between step 3 and 4). If we actually insert the pointer there, it would mess with the protector in thread B in such a way that the later write (step 6) becomes UB.

But the write is not yet actually there. But since we want to allow inserting it there, and since inserting it must not increase the amount of UB, we must ensure that this program already has UB now. This is where the end action comes in, which causes a write at protector end that perturbes the noalias state for thread B in the same way as inserting a write would have.



> The potential counterexamples I can think of all require concurrency

This is indeed true. Sequential code has well-nested protectors where these complications do not arise. Does llubi do concurrency (or plan to do so)?


Also note that for weak (non-sequentially-consistent) memory, the protector end accesses need even more complicated semantics. 

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