[LLVMdev] confused about llvm.memory.barrier

[Jonathan S. Shapiro]

On Thu, 2008-09-25 at 10:28 -0400, Luke Dalessandro wrote:
> When I request a write-before-read memory barrier on x86 I would expect 
> to get an assembly instruction that would enforce this ordering (mfence, 
> xchg, cas), but it just turns into a nop.

In its usual configuration, an x86 family CPU implements a strong memory
ordering constraint for all loads and stores, so as long as the ordering
of the read and write operations is preserved no atomic operation is
required between them. XCHG and CAS only become necessary when you are
coordinating reads and writes across processors. MFENCE similarly.

So the current behavior of LLVM is correct, but there is a valid concern
hiding here: there exist programs that intentionally alter the strong
ordering contract in high-performance applications for the sake of
performance, and in those applications it really is necessary to do some
operation that suitably serializes the memory subsystem on the
processor.

The LLVM team may already have a better answer for this, but my first
reaction is that this is effectively a different target architecture. My
second, and possibly more interesting reaction is that

  a) There needs to be some means (through annotation) to insist that
     these instructions are not removed. Perhaps some means already
     exists; I have not looked.

  b) It might be interesting to examine whether coherency behavior
     could be handled as an attribute of address spaces in LLVM.
     Offhand, this would seem to require a notion of address spaces that
     are exact duplicates of each other except for coherency behavior,
     but there might be some cleaner way to handle that.

The entire LLVM address space notion intrigues me, and I just haven't
had any chance to dig in to it.


shap