[PATCH] D137707: Move "auto-init" instructions to the dominator of their users

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

> Are there any worries about moving stores that are on atomic/volatile "objects", either because the auto-init store itself is atomic/volatile, or because a subsequent access is marked as such? I don't think there's a worry because auto-init stores are technically outside the abstract machine (they "don't exist"), but I'm not 100% convinced.

The thing I'd be concerned about is sinking the store past an atomic fence.

Allocating/initializing an object is never atomic.  The requirement of the abstract machine is that the allocation/initialization of the variable has to have a happens-before relationship with any access to it.  Consider something like the following:

  int x = 3;
  atomic_thread_fence(memory_order_release);
  atomic_store_explicit(y, &x, memory_order_relaxed);

After the atomic store, it's legal for another thread to access the value "3" through the pointer y, or to write another value to x.  (The operations on x don't need to be atomic, as long as the operations on y form a happens-before edge.)  So it's illegal to sink the store of "3" past the fence.

If instead x is uninitialized, you run into basically the same thing with implicit zero init: it's illegal to sink the implicit zero-init of x past the fence, because it could race with stores on another thread.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137707/new/

https://reviews.llvm.org/D137707