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

[Philip Reames via llvm-dev]

On 12/14/2015 04:23 PM, JF Bastien wrote:
>
>>         Would you mind explaining what complexities you see for
>>         vectors?  As per my direct email, the set of vectors which
>>         can practically be made atomic may be smaller than we'd like,
>>         but the existing atomic semantics seem to map cleanly.  What
>>         am I missing?
>>
>>
>>
>>     I'm also concerned about:
>>
>>       * Alignment is the big one, I think we'll want to discuss
>>         having entirely atomic vectors as well as vectors whose
>>         elements are atomic only.
>>
>     Not sure how the second part relates to the first part.  I agree
>     that we probably want a notion of element-wise atomicity for
>     vector (and possibly struct/array) types, but I think that should
>     come later.  Specifically, I think we'd need an alternate spelling
>     for an element-wise for on atomic, so I see no harm in having the
>     support for fully atomic vectors added now.
>
>>       * Having vectors of pointers without fully supporting atomic
>>         pointer.
>>
>     We support atomic pointer operations in loads and stores.  Again,
>     what we support in load/store is currently separate from what we
>     support in atomicrmw/cmpxchg.  We should unify the later with the
>     former, but that's a separate issue.
>
>
> Ha, I didn't realize we did, I though it had to go through intptr 
> casts just like FP does but r162146 added it back in 2012. The 
> documentation and verifier look slightly wrong, here's a proposed fix 
> <http://reviews.llvm.org/D15512>.
Commented on your review.
>
>>       * Vectors of unusual sizes or integer types being atomic, and
>>         how they get legalized. e.g. <3 x i32> or <256 x i1>.
>>
>     Well, the former isn't legal.  It isn't a power of two size.  I'm
>     not suggesting we relax that requirement.
>
>
> Indeed, I'd like to make sure we don't and have some pretty explicit 
> testing for it.
Reasonable.
>
>
>     If it has a power of two store size, then it should get the
>     equivalent handling to an iX of the same size.   I don't see the
>     issue here.  How is the second example any different from an
>     atomic i256?
>
>
> i1 isn't storable as-is :-)
It looks like the backend scalarizes a non-atomic <256 x i1> store into 
256 1 byte stores.  So no, that can't be atomic.  :)

The particular lowering is also terrible.  We should be emitting a small 
loop in this case, not unrolling the entire thing.
>
>
>     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.
>
>
>>       * 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?
>
>
>     p.s. Thanks for asking clarifying questions.  Getting this all
>     hammered out is definitely a good idea.  I just want to make sure
>     we close the loop quickly so that this doesn't get stalled.
>
>
> You mean, more stalled that the holidays will already stall it? ;-)
True.  :)

Philip

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