[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
Mon Dec 14 16:23:46 PST 2015
> 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
> - 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 :-)
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.
> - 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
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