[llvm-branch-commits] [llvm] [SPARC][MC] Add tests for VIS family instructions (PR #130967)

[Sergei Barannikov via llvm-branch-commits]

================
@@ -7,76 +7,96 @@
 //===----------------------------------------------------------------------===//
 //
 // This file contains instruction formats, definitions and patterns needed for
-// VIS, VIS II, VIS II instructions on SPARC.
+// VIS, VIS II, VIS III instructions on SPARC.
 //===----------------------------------------------------------------------===//
 
 // VIS Instruction Format.
 class VISInstFormat<bits<9> opfval, dag outs, dag ins, string asmstr,
-      list<dag> pattern>
+        list<dag> pattern = []>
       : F3_3<0b10, 0b110110, opfval, outs, ins, asmstr, pattern>;
 
-class VISInst<bits<9> opfval, string OpcStr, RegisterClass RC = DFPRegs>
+class VISInst<bits<9> opfval, string OpcStr, RegisterClass RC = DFPRegs,
+        list<dag> pattern = []>
        : VISInstFormat<opfval,
         (outs RC:$rd), (ins RC:$rs1, RC:$rs2),
-        !strconcat(OpcStr, " $rs1, $rs2, $rd"), []>;
+        !strconcat(OpcStr, " $rs1, $rs2, $rd"), pattern>;
 
 // VIS Instruction with integer destination register.
-class VISInstID<bits<9> opfval, string OpcStr>
+class VISInstID<bits<9> opfval, string OpcStr, list<dag> pattern = []>
        : VISInstFormat<opfval,
         (outs I64Regs:$rd), (ins DFPRegs:$rs1, DFPRegs:$rs2),
-        !strconcat(OpcStr, " $rs1, $rs2, $rd"), []>;
+        !strconcat(OpcStr, " $rs1, $rs2, $rd"), pattern>;
 
 // For VIS Instructions with no operand.
 let rd = 0, rs1 = 0, rs2 = 0 in
-class VISInst0<bits<9> opfval, string asmstr>
-       : VISInstFormat<opfval, (outs), (ins), asmstr, []>;
+class VISInst0<bits<9> opfval, string asmstr, list<dag> pattern = []>
+       : VISInstFormat<opfval, (outs), (ins), asmstr, pattern>;
 
 // For VIS Instructions with only rs1, rd operands.
 let rs2 = 0 in
-class VISInst1<bits<9> opfval, string OpcStr, RegisterClass RC = DFPRegs>
+class VISInst1<bits<9> opfval, string OpcStr, RegisterClass RC = DFPRegs,
+        list<dag> pattern = []>
        : VISInstFormat<opfval,
         (outs RC:$rd), (ins RC:$rs1),
-        !strconcat(OpcStr, " $rs1, $rd"), []>;
+        !strconcat(OpcStr, " $rs1, $rd"), pattern>;
 
 // For VIS Instructions with only rs2, rd operands.
 let rs1 = 0 in
-class VISInst2<bits<9> opfval, string OpcStr, RegisterClass RC = DFPRegs>
+class VISInst2<bits<9> opfval, string OpcStr, RegisterClass RC = DFPRegs,
+        list<dag> pattern = []>
        : VISInstFormat<opfval,
         (outs RC:$rd), (ins RC:$rs2),
-        !strconcat(OpcStr, " $rs2, $rd"), []>;
+        !strconcat(OpcStr, " $rs2, $rd"), pattern>;
 
 // For VIS Instructions with only rd operand.
 let Constraints = "$rd = $f", rs1 = 0, rs2 = 0 in
-class VISInstD<bits<9> opfval, string OpcStr, RegisterClass RC = DFPRegs>
+class VISInstD<bits<9> opfval, string OpcStr, RegisterClass RC = DFPRegs,
+        list<dag> pattern = []>
----------------
s-barannikov wrote:

IMHO `Pat` is a much cleaner way to define patterns. Currently, there are multiple issues involving patterns that are not obvious because the patterns are inline. For instance, we don't have patterns for some extending loads (IIRC), which results in suboptimal codegen. Having those patterns defined in one place rather thann scattered across large files would make the issue obvious.

There is one downside of using `Pat` that you should be aware of: one has to duplicate feature checks on `Pat` from instruction definition. This may not be a big issue though as it is possible to do something like this:
```
let Predicates = [FeatureVIS] in {
// multiple patterns here
}
```


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