[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types
Craig, Ben via llvm-dev
llvm-dev at lists.llvm.org
Wed Dec 16 06:05:34 PST 2015
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?
>> 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:
>> 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.
> 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
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...
More information about the llvm-dev