[LLVMdev] confused about llvm.memory.barrier

[David Greene]

On Thursday 25 September 2008 09:41, Jonathan S. Shapiro wrote:

> 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.

That's not quite true.  If you use non-temporal stores you need a way to 
generate a real mfence.

> 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.

This is going to become more and more common on x86.

> 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

No, it's not a separate target architecture.  That would be overkill.

>   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.

As Luke discovered, it's the argument to llvm.memory.barrier that make the
difference.  See X86InstrSSE.td.

>   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.

That's an interesting thought as that's exactly how WC and non-WC
memory is described in the Opteron manuals.

                                                              -Dave