[cfe-dev] __sync_synchronize doesn't generate a memory barrier

[Jim Grosbach]

I've been most active on it for ARM, but I'm somewhat familiar with how x86 handles this stuff, yes. I strongly suspect this behaviour is entirely for compatibility purposes with GCC.

Other than that, I'm not aware of any reason we shouldn't generate actual instructions for the intrinsics.

-Jim

On May 22, 2011, at 10:56 AM, Evan Cheng wrote:

> I think Jim worked on this.
> 
> Evan
> 
> On May 22, 2011, at 9:52 AM, Chris Lattner wrote:
> 
>> Adding Owen :)
>> 
>> -Chris
>> 
>> On May 9, 2011, at 10:38 AM, Arlen Cox wrote:
>> 
>>> Why does __sync_synchronize() not generate a mfence instruction on x86
>>> and x86_64?  I recognize that Apple gcc does not do this either, but I
>>> believe this is a bug in Apple gcc as well.  More recent versions of
>>> gcc implement a correct behavior (mfence on x86_64 and lock orl $0,
>>> (%esp) on x86), but clang emits no code for this operation.
>>> 
>>> LLVM supports an instruction that emits the correct memory barrier:
>>> call void @llvm.memory.barrier(i1 true, i1 true, i1 true, i1 true, i1 true)
>>> but Clang uses the following, which seems to have no effect on x86:
>>> call void @llvm.memory.barrier(i1 true, i1 true, i1 true, i1 true, i1 false)
>>> 
>>> This matters for multi-threaded code as memory barriers are the only
>>> way we can force an ordering on loads and stores.
>>> 
>>> Thanks,
>>> Arlen
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>