llvm dev - Dec 2015 - RFC: Extending atomic loads and stores to floating point and vector types

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

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>

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>