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

>
> Actually, this brings up a related issue.  We seem to have no
>> documentation in the lang ref about how vector types are represented in
>> memory.  The actual implementation appears to assumed packed bits, but
the
>> docs don't say.  Depending on what the semantics here are, my
assumptions
>> in the last two paragraphs may not be valid.
>>
>
> Indeed!
>
> Any clue how to start specifying this?  It would seem to be ABI
> dependent.
>
Maybe start a new threads here describing the problem? I don't really know
otherwise.


>>    - 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151215/3f191ddb/attachment.html>

On 12/15/2015 04:02 PM, JF Bastien wrote:
>
>>         Actually, this brings up a related issue.  We seem to have no
>>         documentation in the lang ref about how vector types are
>>         represented in memory.  The actual implementation appears to
>>         assumed packed bits, but the docs don't say.  Depending on
>>         what the semantics here are, my assumptions in the last two
>>         paragraphs may not be valid.
>>
>>
>>     Indeed!
>     Any clue how to start specifying this?  It would seem to be ABI
>     dependent.
>
>
> Maybe start a new threads here describing the problem? I don't really 
> know otherwise.
Will do.
>
>
>>>           * 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?

Philip

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

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