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

JF Bastien via llvm-dev llvm-dev at lists.llvm.org
Tue Dec 15 16:21:12 PST 2015

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

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>

More information about the llvm-dev mailing list