Differential D117499
[CodeGen] Support extracting fixed-length vectors from illegal scalable vectors Authored by david-arm on Jan 17 2022, 8:46 AM.
Details For some indices we can simply extract the fixed-length subvector from the Fixes https://github.com/llvm/llvm-project/issues/55412 Tests added here: CodeGen/AArch64/sve-extract-fixed-from-scalable-vector.ll
Diff Detail Event TimelineComment Actions Any thoughts on lowering to the stack, vs. generating "select" operations? If I'm not mistaken, at least for SVE, we should always be extract elements from exactly one half of the split. Not sure how much it matters in practice, though. Do we need to special-case i1 vectors? Comment Actions I had a look into using selects, but it doesn't work because when selecting between lo and hi parts you end up constructing a non-constant index for the hi part, i.e. IdxVal - LoNumElts (which is not a constant for scalable vectors). This leads to asserts because EXTRACT_SUBVECTOR is defined to only take constant indices. I don't think we have to do anything special for i1 vectors because if the i1 type gets promoted (i.e. NEON), then we will end up down a different path where we extract individual elements from an illegal scalable vector, which is dealt with in SplitVecOp_EXTRACT_VECTOR_ELT. This is why in @extract_v4i1_nxv32i1_16 we end up spilling the input four times - once for each EXTRACT_VECTOR_ELT. If the i1 type is legal then presumably there will also be legal loads for them too.
Comment Actions
You could handle the special case where the offset only points into the high vector if vscale is exactly 1. Actually, more generally, if vscale is a power of two, there's exactly one value of vscale that would make the EXTRACT_SUBVECTOR point into the high vector: given a pair of index/vscale that points into the high vector, if vscale is smaller, it's UB, and if vscale is larger, it points into the low vector. So we can construct an appropriate constant. I guess we don't promise that vscale is a power of two in general, though. If we allow for the possibility that vscale isn't a power of two, then yes, you'd need some sort of variable shuffle or load/store in general.
The issue would be on a target where a type like v4i1 is legal. i1 vectors are tightly packed in memory, so v1i1, v2i1, v4i1, and v8i1 are all one byte, so you can't just load the part you want.
Comment Actions Hi @efriedma,
But if both the result (say a v4i1) and the broken-down input (say a nxv32i1, broken down into nxv16i1) are both legal, then they will both be equally packed in the same way so this should be safe I think? Unless I've misunderstood something it sounds like the problem you're worried about is when the result is packed and the input stored on to the stack is unpacked, right? If so, I don't think I can really write a test case for this because I don't know of any targets that both support scalable vectors and have legal fixed-width predicate vectors. Perhaps I can just add an unreachable for cases like that? Comment Actions Say you're trying to extract a v4i1 from an nxv8i1, with index 4. If you store the nxv8i1 to the stack, then load it as v4i1, you get the elements at index 0, since the first 8 elements of nxv8i1 are all packed into a single byte. (Note that SVE doesn't have any native instruction that's equivalent to an nxv2i1/nxv4i1/nxv8i1 store. Currently, it doesn't come up because nothing emits such operations.)
True. Comment Actions
Comment Actions Hi @efriedma, if it's ok with you I'd like to leave the spilling and reloading from the stack if that's ok? As you say, there may be situations where we can improve this with a select, but the crux of this patch is to fix a bug. If we see performance issues in future we can always revisit this? I've also added checks for the case you described, extracting a legal fixed-width predicate subvector. Comment Actions I'm okay with skipping the select optimization for now, sure.
Comment Actions
| |||||||||||||||||||||||||||||||||
Drop else after return