[llvm] [RISCV][GISEL] instruction-select for G_SPLAT_VECTOR (PR #111193)

[Tobias Stadler via llvm-commits]

tobias-stadler wrote:

> SelectionDAG does not have patterns for G_SPLAT_VECTOR. It only has patterns for G_VMV_V_X_VL and G_VFMV_V_F_VL. As noted earlier, SelectionDAG has a pre-isel peephole to change the opcode. This is done because VP intrinsics directly use the G_VMV_V_X_VL and G_VFMV_V_F_VL opcodes since they come with a VL. Generic shufflevector does not come with a VL so use SPLAT_VECTOR. We standardize on one opcode using the peephole to reduce the isel table size.
> 
> There are something like 14 different opcodes that need to be selected based on the opcode and the type. Since those are already in the isel table we would like to use that and not repeat the 14 opcodes manually.
> 

Then we don't need to put this into earlySelect(). Can we just add the following (pseudo code) to the big selection switch?
```
case G_SPLAT_VECTOR:
MI1 = buildConstant();
MI2 = build(G_VMV...)
select(MI2);
select(MI1);
return true;
```
In this way we select G_VMV before the constant and G_VMV is selected by the imported SelectionDAG patterns. No preISelLower hack necessary.

> I'm not even sure doing the switch from G_SPLAT_VECTOR to G_VMV_V_X_VL and G_VFMV_V_F_VL makes sense. In SelectionDAG, we do the switch before any instructions are selected. We have patterns to fold vector arithmetic with a splat operand into special instructions too. Those patterns expect G_VMV_V_X_VL/G_VFMV_V_F_VL. If we don't do the switch until the G_SPLAT_VECTOR is eligible for selection, these arithmetic patterns won't match. I believe those patterns use a ComplexPattern to match the operand so maybe we can also check SPLAT_VECTOR there for GISel and this won't really be a problem.

In my opinion matching target-specific opcodes is a hack, and we should want to fix this for GISel by matching the generic opcode. No idea if the importer can handle this though.


https://github.com/llvm/llvm-project/pull/111193