[LLVMdev] RFC: Atomics.h

[Luke Dalessandro]

Luke Dalessandro wrote:
> Jeffrey Yasskin wrote:
>> What would you do with a just-hardware memory fence? If the compiler's
>> free to move operations over the hardware fence, that seems to defeat
>> the purpose.
> 
> If your compiler memory fence (gcc's __sync_synchronize()) doesn't 
> distinguish different kinds of fencing requirements, and your platform 
> has different hardware fences with different costs (isync, lwsync, 
> eieio, etc), then it can make sense to separate the two using something 
> like asm volatile(::"memory") for the compiler fence. It gets pretty 
> architecture dependent though.

To reply to my reply, most sane implementations of these memory barriers 
would imply the compiler fence by slapping a memory clobber on the 
underlying asm, so you're point is well taken. I have seen cross 
platform code where they are separated though for whatever reason though.

Luke

> 
> Luke
> 
>> C++0X provides a compiler-only fence, and a hardware+compiler fence,
>> but no hardware-only fence, I believe for this reason. See
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf>,
>> section 29.8.
>>
>> On Sat, May 16, 2009 at 7:33 PM, Owen Anderson <resistor at mac.com> wrote:
>>> Surprisingly enough, libatomic_ops doesn't define just a hardware memory
>>> fence call as far as I can tell.
>>> --Owen
>>> On May 16, 2009, at 3:00 PM, Zoltan Varga wrote:
>>>
>>> Hi,
>>>
>>>   You might want to use this:
>>>
>>> http://www.hpl.hp.com/research/linux/atomic_ops/
>>>
>>>                              Zoltan
>>>
>>> On Sat, May 16, 2009 at 11:11 PM, Owen Anderson <resistor at mac.com> wrote:
>>>> Some of you may have noticed that I addedd include/llvm/System/Atomics.h
>>>> to the repository briefly, which will be used for adding support for
>>>> threading in LLVM.
>>>>
>>>> I have tried to provided appropriate implementations of the atomic ops
>>>> (currently memory fence and CAS) for platforms we care about, but my
>>>> knowledge of these, and my ability to test them, is limited.  So, please, if
>>>> you run on any less common platform, test out the file, and send me patches
>>>> to improve it if it doesn't work verbatim on your system.
>>>>
>>>> Thanks,
>>>>
>>>> --Owen
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev