I'd guarded this case in D158874 to avoid regressions, and decided to go investigate what was going on. The solution turns out to be a generic splat matching extension to handle INSERT_SUBVECTOR. In theory, we could see these from other sources as well, but for some reason we only seem to see the i64 extract on rv32 case in practice. Not sure why that is to be honest.
Details
Details
Diff Detail
Diff Detail
Event Timeline
llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp | ||
---|---|---|
2959 | Are we getting multiple nested insert_subvectors? If their vector operands are undef shouldn't they be getting combined away? I found this combine in DAGCombiner.cpp: // Eliminate an intermediate insert into an undef vector: // insert_subvector undef, (insert_subvector undef, X, 0), N2 --> // insert_subvector undef, X, N2 if (N0.isUndef() && N1.getOpcode() == ISD::INSERT_SUBVECTOR && N1.getOperand(0).isUndef() && isNullConstant(N1.getOperand(2))) return DAG.getNode(ISD::INSERT_SUBVECTOR, SDLoc(N), VT, N0, N1.getOperand(1), N2); |
llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp | ||
---|---|---|
2959 | Not that I saw, I can remove the loop if desired. This is just replacing the "while" with an "if". |
Are we getting multiple nested insert_subvectors? If their vector operands are undef shouldn't they be getting combined away? I found this combine in DAGCombiner.cpp: