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

[Philip Reames via llvm-dev]

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.
>>
>>
>>     Indeed!
>     Any clue how to start specifying this?  It would seem to be ABI
>     dependent.
>
>
> Maybe start a new threads here describing the problem? I don't really 
> know otherwise.
Will do.
>
>
>>>           * 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?

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151215/6079d3ea/attachment.html>