[LLVMdev] confused about llvm.memory.barrier

[Luke Dalessandro]

Jonathan S. Shapiro wrote:
> 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.

IA32 (http://www.intel.com/products/processor/manuals/318147.pdf) always 
allows load bypassing.

I found the problem. llvm-gcc compiles __sync_synchronize() ("a full 
memory barrier") as:

1. tail call void @llvm.memory.barrier(i1 true, i1 true, i1 true, i1 
true, i1 false)

As pointed out on IRC, that 5th parameter being false is what is 
generating the nop. If I go in and manually change it to true I get the 
mfence.

Did llvm.memory.barrier always have 5 parameters? What's the purpose of 
the 5th? Why isn't requesting a ls barrier enough?

I think this might be a change that llvm-gcc doesn't know about yet (yet 
== r56496).

Luke

> 
> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev