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

[Philip Reames via llvm-dev]

On 12/15/2015 04:21 PM, JF Bastien wrote:
>
>>>>               * 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.
Do they end up using the same lock though?  If not, we'd still have a 
race and break atomicity.

Also, what about the case of partially overlapping accesses?  The code 
you linked to seems to only handle the case where the base and size of 
the access regions match exactly.

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151215/5bf44c20/attachment-0001.html>