[llvm] [RISCV] Add codegen support for ri.vinsert.v.x and ri.vextract.x.v (PR #136708)

[Philip Reames via llvm-commits]

================
@@ -9686,6 +9693,26 @@ SDValue RISCVTargetLowering::lowerINSERT_VECTOR_ELT(SDValue Op,
         return Vec;
       return convertFromScalableVector(VecVT, Vec, DAG, Subtarget);
     }
+
+    // Use ri.vinsert.v.x if available.
+    if (Subtarget.hasVendorXRivosVisni() && VecVT.isInteger() &&
+        isValidVisniInsertExtractIndex(Idx)) {
+      unsigned Policy = RISCVVType::TAIL_UNDISTURBED_MASK_UNDISTURBED;
+      if (VecVT.isFixedLengthVector() && isa<ConstantSDNode>(Idx) &&
+          Idx->getAsZExtVal() + 1 == VecVT.getVectorNumElements())
+        Policy = RISCVVType::TAIL_AGNOSTIC;
+      SDValue PolicyOp =
+          DAG.getTargetConstant(Policy, DL, Subtarget.getXLenVT());
+      Vec = DAG.getNode(RISCVISD::RI_VINSERT_VL, DL, ContainerVT, Vec, Val, Idx,
----------------
preames wrote:

> Do we end up needing the VL/policy operands if the VL here is always the "full vector" from `getDefaultVLOps`?

On VL, having it is mostly to keep code consistency with vmv.s.x which makes the same choice.  Note that this instruction has the same zero vs non-zero behavior difference as vmv.s.x.  

On policy, there's an ambiguity in the specification on the definition of tail elements for this instruction.  I'd interpreted it as needing a policy for elements beyond VLMAX (consider mf2).  I'm asking for clarification internally, and will update the specification with the answer.

> I think this is also causing the VL > VLMAX in the insertelt_v32i32_4 test case.

See my response to your comment on the test.  


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