[llvm-dev] RFC: Extending atomic loads and stores to floating point and vector types
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Tue Dec 15 16:09:25 PST 2015
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.
> Any clue how to start specifying this? It would seem to be ABI
> 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?
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev