[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?
> 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...
More information about the llvm-dev