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

[Craig, Ben via llvm-dev]

On 12/15/2015 7:06 PM, JF Bastien via llvm-dev wrote:
> On Tue, Dec 15, 2015 at 4:27 PM, Philip Reames 
> <listmail at philipreames.com <mailto: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.
Here are some gcc docs describing inlining atomics vs. making library 
calls.  The intro explicitly covers inter-compiler compatibility.
https://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary

>
>
>     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 :-)
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151216/0ac82233/attachment.html>