VT::NumElements is replaced by VT::ElementCount with the later holding the minimum #Elements along with a scalable flag. This leads to three scenarios: 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 today. This patch extends VectorType with an ElementCount based interface along with IR parsing/writing and bitcode changes to support scalable vector types.
Details
Diff Detail
- Build Status
Buildable 1587 Build 1587: arc lint + arc unit
Event Timeline
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.
Hi Paul,
I have a few inline comments, but there are two huge questions about this patch:
- 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.
- 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.
cheers,
--renato
docs/LangRef.rst | ||
---|---|---|
6722 | 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). | |
6806 | 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. | |
include/llvm/IR/DerivedTypes.h | ||
368 | Same here, keep the old notation to avoid mismatch with current comments. | |
372 | You mention the "latter" but gives an example of each. I think you can stop at "discarded", then mention examples below. | |
419 | I don't think ElementCount should be exposed to the user. The constructor below is essentially identical. | |
lib/IR/Type.cpp | ||
641 | 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.
cheers,
--renato
lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
2125 | 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. | |
2133 | 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. |
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).