[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 15:10:27 PST 2015
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
> 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
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.
> 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.
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? ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev