[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types

[JF Bastien via llvm-dev]

>
>
>>>    - Once we add vector, should we consider adding other composite
>>>    types in general, including structs? C++ allows this, but has substantial
>>>    issues w.r.t. padding.
>>>
>>> I'd say possibly, but FCAs are poorly supported in the IR in general.  I
>>> am not willing to block changes for vectors on changes for FCAs.  This has
>>> never been our policy in the past and should not become so now.
>>>
>>
>> Oh yeah I don't think we should block it. FWIW I expect that some of
>> these will generate calls to the runtime's global atomic lock shard, which
>> is horrible.
>>
>> "global atomic lock shard"?  I have no idea what you're referring to.  Is
>> that something in libc?
>>
>
> compiler-rt:
> https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/atomic.c
>
> Hm, I think this raises an interesting semantic question.  We could use
> the global lock shard scheme to make loads atomic w.r.t. other llvm emitted
> writes, but not writes emitted by other compilers.  This would mean that
> linking object files with atomics might break their atomicity.  I'm not
> sure we want to allow that.  Maybe we can do that only if the
> synchronization scope allows it or something?
>

GCC does it in libatomic:
https://github.com/gcc-mirror/gcc/tree/master/libatomic

They agree on the function name, so AFAIK either runtime allows this to
work properly: the compiler just emits a call to the function, and one of
the runtimes has to be present.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151215/6e0d34cc/attachment.html>