[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
Mon Dec 14 13:26:53 PST 2015
On 12/14/2015 12:46 PM, JF Bastien wrote:
> On Mon, Dec 14, 2015 at 11:46 AM, Philip Reames
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
> On 12/12/2015 01:44 PM, JF Bastien wrote:
>> On Sat, Dec 12, 2015 at 1:24 AM, Philip Reames
>> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>> Patch posted for review: http://reviews.llvm.org/D15471
>> Looking at the patch, I think we should do FP only for now as
>> vectors have extra complexities which IMO warrant more discussion.
> I'm fine with splitting the patch up to make progress. I'll post a
> split patch shortly.
> Thanks. FWIW I think we'll want to do vectors, but I think it's
> trickier than just FP.
> 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.
> * 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.
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?
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev