[LLVMdev] llvm.memory.barrier does not work

[Eli Friedman]

On Thu, Sep 29, 2011 at 9:16 AM, Junjie Gu <jgu222 at gmail.com> wrote:
> On Wed, Sep 28, 2011 at 5:47 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Wed, Sep 28, 2011 at 3:27 PM, Junjie Gu <jgu222 at gmail.com> wrote:
>>> Instrinsic llvm.memory.barrier does not work as expected.  Is it a bug
>>> or it has not been implemented yet ?
>>
>> It's going away in favor of the new fence instruction (and I'll remove
>> it as soon as dragonegg catches up).  It should still work at the
>> moment, though.
>>
>>> (1) false arguments do not work
>>>
>>> // pesudo code
>>> void foo(int *x) {
>>>  x[2] = 10;
>>>  llvm.memory.barrier(0, 0, 0, 0, 0);
>>>   x[2] = 20;
>>>  return void
>>> }
>>>
>>>
>>> The barrier is actually noop,  but it prevents "x[2] = 10" from being deleted.
>>
>> Don't do that. :)  Really, why are you using a noop barrier?
>
> Just to show it affects optimization, but it shouldn't.
>
>>
>>> (2) True arguments do not work.
>>>
>>> // pesudo code
>>> void foo(int * restrict x) {
>>>  x[2] = 10;
>>>  llvm.memory.barrier(1, 1, 1, 1, 1);
>>>   x[2] = 20;
>>>  return void
>>> }
>>>
>>> "x[2] = 10' should not be deleted because barrier is present.  But it
>>> is deleted anyway.
>>
>> The pointer is "restrict", therefore the compiler assumes nothing else
>> can touch it while the function runs.
>>
>> Actually, the transformation in question is probably valid even if the
>> pointer isn't restrict (although LLVM won't actually do that); your
>> use of a barrier here doesn't really make sense.
>
> If you think of multiple-threaded code,  it will make sense.  Again,
> this is a simplied code and is used just for showing the point.
>
> The memory barrier requires that all memory operations prior to the
> barrier point completes before any memory operations after the barrier
> start.  I think that it requires that compilers do not optimize across
> the barrier point (and compilers do generate memory barrier
> instructions if needed. I think LLVM only does this.),  do you agree
> on this ?

memory.barrier's semantics aren't really all that well defined.  Which
is why we're replacing it; the new fence instruction is clearly
defined based on C++0x semantics.

-Eli