ExpandVectorBuildThroughStack is also used for CONCAT_VECTORS.
However, when calculating the offsets for each of the operands we
incorrectly use the element size rather than actual size and thus
the stores overlap.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/CodeGen/AArch64/sve-fixed-length-shuffles.ll | ||
---|---|---|
14 | The tests are a little looser than I'd like but this mov prevents me from using CHECK-DAG because there's a similar unrelated mov that's part of the function prolog. |
LGTM
llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp | ||
---|---|---|
1429 | Nit: Not specific to this patch, but I think we can hoist Node->getOperand(i).getValueType() out of the loop. All the BUILD_VECTOR/CONCAT_VECTOR operand types should be the same. Looking deeper, the BUILD_VECTOR description is a little vague though: /// The types of the operands must all be /// the same and must match the vector element type, except that integer types /// are allowed to be larger than the element type, in which case the operands /// are implicitly truncated. I assume the larger integer operand types must all be the same type. Maybe I'm misinterpreting this though. Just queried llvm-dev about BUILD_VECTOR and will report back... |
llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp | ||
---|---|---|
1429 | It seems that the operands must always have the same type, but there's a modicum of disagreement (uncertainty?) there. No reason to hold up this patch though. |
Nice, thank you. @davidb this probably means you can drop the TargetConcatVectors ISD node from your llc.
Nit: Not specific to this patch, but I think we can hoist Node->getOperand(i).getValueType() out of the loop. All the BUILD_VECTOR/CONCAT_VECTOR operand types should be the same.
Looking deeper, the BUILD_VECTOR description is a little vague though:
I assume the larger integer operand types must all be the same type. Maybe I'm misinterpreting this though.
Just queried llvm-dev about BUILD_VECTOR and will report back...