Ok, so the semantics of your fence would be that it's a volatile
memory access (http://llvm.org/docs/LangRef.html#volatile-memory-accesses),
and that it provides happens-before edges for volatile accesses in the
same way that a seq_cst fence provides for atomic accesses.
FWIW, I don't think we should add that, because it's an attempt to
define behavior that's undefined for other reasons (the data race on
the volatile).
If you (PNaCl?) explicitly want to define the behavior of legacy code
that used 'volatile' for synchronization (which has always been
undefined behavior outside of assembly, even before the memory model;
it just happened to work in many cases), could you compile volatile
accesses to 'atomic volatile monotonic' accesses? Then the normal
memory model would apply, and I don't think the instructions emitted
would change at all on the platforms I'm familiar with.
Jeffrey