Page MenuHomePhabricator

[Type] Extend VectorType to support scalable vectors. [IR support for SVE scalable vectors 1/4]

Authored by paulwalker-arm on Nov 24 2016, 6:41 AM.


VT::NumElements is replaced by VT::ElementCount with the later holding
the minimum #Elements along with a scalable flag.  This leads to three

1. The vector length is treated as opaque and thus calls to
getNumElements become getElementCount.
2. The vector length is being scaled (doubled/halved) in which case
calls to getNumElements become getElementCount and the arithmetic
remains the same.
3. The code does not support scalable vectors in which case it is
protected by !isScalable() and operates on getNumElements as it does

This patch extends VectorType with an ElementCount based interface along
with IR parsing/writing and bitcode changes to support scalable vector

Event Timeline

paulwalker-arm retitled this revision from to [Type] Extend VectorType to support scalable vectors. [IR support for SVE scalable vectors 1/4].
paulwalker-arm updated this object.
paulwalker-arm added reviewers: hfinkel, nadav.
paulwalker-arm added a subscriber: llvm-commits.
fhahn added a subscriber: fhahn.Nov 24 2016, 6:52 AM
mkuper edited edge metadata.Nov 25 2016, 7:01 AM

Hi Paul,

I think this is not the right set of reviewers for this part of the patch sequence.

I'll be happy to review vectorizer changes to support SVE, but for the initial sweeping IR level changes, you'll want more people with a high-level view - this doesn't only affect the vectorizer, this is something the entire midend has to deal with.

rengolin edited edge metadata.Nov 29 2016, 6:08 AM

Hi Paul,

I have a few inline comments, but there are two huge questions about this patch:

  1. Is this the right move?

This will be answered by a more thorough review on all the possibilities, representations and future expansions of the IR. I haven't spotted any backwards incompatibility, but I could be wrong. There is the obvious forwards incompatibility, which is less serious but non-trivial.

I'll let people comment on that, but from my side, the new representation looks good for what's intended.

  1. Can we do it now?

With the release 4.0 branching off any time in December, we may be asked to hold off big IR changes if they have any visible impact on everyone else's work. Your PackedEC representation is a big one, because it will produce large values for those IR readers that don't understand it (ie. all projects that follow releases or old trunk and have to interact with upstream IR).

I don't know off the top of my head which problems they are or who has them, so we'll have to wait for people to shed some light on that, here.

Finally, tests. I'm surprised if those two new lines are all we have on vector parsing, printing and validating. I don't really know where the tests are, but we probably have more than that. We'll need tests parsing different types of vectors, different types of failures (like <4 x n x i32>), etc. Also, make sure to include an example of scalable vectors on each new LangRef topic.



For purely notational reasons, we may want to keep the "n" as the primary multiplier, since it's already widely commented and documented across the code and docs. Pick another unambiguous constant symbol, like "k", or even "m" (from "multiples" of vectors).


I'm uncertain about this one. How will the masks look like?

Say, for instance, on a zip operation. On normal vectors, it's something like:

%tmp = shufflevector <4 x i32> %v1, <4 x i32> %v2,
                     <8 x i32> <i32 0, i32 4, i32 1, i32 5, i32 2, i32 6, i32 3, i32 7>
%newv1 = shufflevector <8 x i32> %tmp, <8 x i32> undef,
                       <4 x i32> <i32 0, i32 1, i32 2, i32 3>
%newv2 = shufflevector <8 x i32> %tmp, <8 x i32> undef,
                       <4 x i32> <i32 4, i32 5, i32 6, i32 7>

and can only be represented in IR because the length is known at compile time. Anything based on "vscale" will be a really complicated pattern and won't work for all cases even if some of them are simple.


Same here, keep the old notation to avoid mismatch with current comments.


You mention the "latter" but gives an example of each. I think you can stop at "discarded", then mention examples below.


I don't think ElementCount should be exposed to the user. The constructor below is essentially identical.


unsigned int is not guaranteed to be 32-bits

Hi Paul,

I want to restart the scalable vector discussion. My original inline comments are still valid and I have a few more.

I think the general idea is sound and in line with a generic "scalable" vector, as well as with how SVE vectors should be represented.



I think this would be much clearer if you stick to 0, 1, 2 indexes rather than "Size - x". We guarantee (in the language) that size is either 2 or 3 or invalid.


Why "Record[Size - 3]"? I'd say...

bool Scalable = Size > 2 ? true : false;

as guaranteed by the language reference (and your comment in DerivedTypes.h.

sanjoy added a subscriber: sanjoy.May 7 2017, 3:44 PM
paulwalker-arm abandoned this revision.May 11 2017, 4:22 AM