In vectorizeChainsInBlock we try to collect chains of PHI nodes
that have the same element type, but the code is relying upon
the implicit conversion from TypeSize -> uint64_t. For now, I have
modified the code to ignore PHI nodes with scalable types.
Details
Diff Detail
Event Timeline
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
7396 | Should the check for scalable (+ corresponding code to bail out) be hoisted out of the if (EltTy->isSized()) condition/block? |
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
7396 | I'm not sure really. This change fixes the case I was interested, but not sure what it means if a type is not sized *and* scalable? I assumed that if a type wasn't sized then you couldn't call getTypeSizeInBits and hope to get a sensible answer. We only know if the type is scalable or not by asking for the TypeSize. |
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
7396 | Any further thoughts on this @sdesmalen ? If it's not sized then I can't ask the question if it's scalable or not. |
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
7396 | The isSized() check here is nonsense: an instruction can't have an unsized result or operand type. |
Hi @efriedma I tried removing the isSized() check and added an assert instead. I tested it and none of our tests broke! Or would you prefer me to just remove the assert completely?
LGTM
The assertion is probably a little excessive, but someone thought it was worth checking for at some point, so it's okay.
Should the check for scalable (+ corresponding code to bail out) be hoisted out of the if (EltTy->isSized()) condition/block?