[RISCV] Add RISCVISD::VQDOT*_VL to RISCVSelectionDAGInfo::verifyTargetNode.

[topperc]

After seeing the bug that #142185 fixed, I thought it might be a good idea to start verifying that nodes are formed correctly.

This patch introduces the verifyTargetNode function and adds these opcodes. More opcodes can be added in later patches.

[llvmbot]

@llvm/pr-subscribers-backend-risc-v

Author: Craig Topper (topperc)

Changes

After seeing the bug that #142185 fixed, I thought it might be a good idea to start verifying that nodes are formed correctly.

This patch introduces the verifyTargetNode function and adds these opcodes. More opcodes can be added in later patches.

---

Full diff: https://github.com/llvm/llvm-project/pull/142202.diff

2 Files Affected:

• (modified) llvm/lib/Target/RISCV/RISCVSelectionDAGInfo.cpp (+32)
• (modified) llvm/lib/Target/RISCV/RISCVSelectionDAGInfo.h (+3)

diff --git a/llvm/lib/Target/RISCV/RISCVSelectionDAGInfo.cpp b/llvm/lib/Target/RISCV/RISCVSelectionDAGInfo.cpp
index 4ebf13f5bc538..d0e7e4d7ed79a 100644
--- a/llvm/lib/Target/RISCV/RISCVSelectionDAGInfo.cpp
+++ b/llvm/lib/Target/RISCV/RISCVSelectionDAGInfo.cpp
@@ -17,3 +17,35 @@ RISCVSelectionDAGInfo::RISCVSelectionDAGInfo()
     : SelectionDAGGenTargetInfo(RISCVGenSDNodeInfo) {}
 
 RISCVSelectionDAGInfo::~RISCVSelectionDAGInfo() = default;
+
+void RISCVSelectionDAGInfo::verifyTargetNode(const SelectionDAG &DAG,
+                                             const SDNode *N) const {
+#ifndef NDEBUG
+  switch (N->getOpcode()) {
+  default:
+    return SelectionDAGGenTargetInfo::verifyTargetNode(DAG, N);
+  case RISCVISD::VQDOT_VL:
+  case RISCVISD::VQDOTU_VL:
+  case RISCVISD::VQDOTSU_VL: {
+    assert(N->getNumValues() == 1 && "Expected one result!");
+    assert(N->getNumOperands() == 5 && "Expected five operands!");
+    EVT VT = N->getValueType(0);
+    assert(VT.isScalableVector() && VT.getVectorElementType() == MVT::i32 &&
+           "Expected result to be an i32 scalable vector");
+    assert(N->getOperand(0).getValueType() == VT &&
+           N->getOperand(1).getValueType() == VT &&
+           N->getOperand(2).getValueType() == VT &&
+           "Expected result and first 3 operands to have the same type!");
+    EVT MaskVT = N->getOperand(3).getValueType();
+    assert(MaskVT.isScalableVector() && MaskVT.getVectorElementType() == MVT::i1 &&
+           MaskVT.getVectorElementCount() == VT.getVectorElementCount() &&
+           "Expected mask VT to be an i1 scalable vector with same number of "
+           "elements as the result");
+    assert((N->getOperand(4).getValueType() == MVT::i32 ||
+            N->getOperand(4).getValueType() == MVT::i64) &&
+           "Expect VL operand to be i32 or i64");
+    break;
+  }
+  }
+#endif
+}
diff --git a/llvm/lib/Target/RISCV/RISCVSelectionDAGInfo.h b/llvm/lib/Target/RISCV/RISCVSelectionDAGInfo.h
index 4757571fb3de4..641189f8661c1 100644
--- a/llvm/lib/Target/RISCV/RISCVSelectionDAGInfo.h
+++ b/llvm/lib/Target/RISCV/RISCVSelectionDAGInfo.h
@@ -31,6 +31,9 @@ class RISCVSelectionDAGInfo : public SelectionDAGGenTargetInfo {
 
   ~RISCVSelectionDAGInfo() override;
 
+  void verifyTargetNode(const SelectionDAG &DAG,
+                        const SDNode *N) const override;
+
   bool hasPassthruOp(unsigned Opcode) const {
     return GenNodeInfo.getDesc(Opcode).TSFlags & RISCVISD::HasPassthruOpMask;
   }

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[preames]

LGTM

Could we generate this from the tblgen descriptions? I was a bit surprised we weren't already.

[lenary]

Can't this be done with tablegen SDTypeProfile? I think that's what the generated version is using, and seems easier to maintain maybe?

[s-barannikov]

Can't this be done with tablegen SDTypeProfile? I think that's what the generated version is using, and seems easier to maintain maybe?

It's still on my backlog. Sorry it is taking so long.

I was a bit surprised we weren't already.

Currently, it only validates the result/operand count and chain/glue operands/results. SDTypeConstraint bits are generated, but are not used yet. There is also an unresolved issue with HWMode-dependent types, they are currently skipped (not included in the tables).