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

[JF Bastien via llvm-dev]

On Tue, Dec 15, 2015 at 4:27 PM, Philip Reames <listmail at philipreames.com>
wrote:

>
>
> 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.
>

I believe this is the intent.


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.
>

That would be UB :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151215/1cda3003/attachment.html>