[llvm] [RISCV] Add scheduling information for SiFive VCIX (PR #86093)

Michael Maitland via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 25 06:14:33 PDT 2024


================
@@ -307,44 +307,44 @@ multiclass VPseudoVC_X<LMULInfo m, DAGOperand RS1Class,
                        Operand OpClass = payload2> {
   let VLMul = m.value in {
     let Defs = [VCIX_STATE], Uses = [VCIX_STATE] in {
-      def "PseudoVC_" # NAME # "_SE_" # m.MX : VPseudoVC_X<OpClass, RS1Class>;
-      def "PseudoVC_V_" # NAME # "_SE_" # m.MX : VPseudoVC_V_X<OpClass, m.vrclass, RS1Class>;
+      def "PseudoVC_" # NAME # "_SE_" # m.MX : VPseudoVC_X<OpClass, RS1Class>, Sched<[!cast<SchedWrite>("WriteVC_" # NAME # "_" # m.MX)]>;
----------------
michaelmaitland wrote:

One example of how this exists for other instructions is that "vector ALU ops" might be grouped together because they are expected to behave similarly on all subtargets. Then someone will come along and say "instruction X that is currently grouped with the vector ALU ops behaves differently from other VALU ops on subtarget Y" and that justifies us creating separate scheduler classes for that instruction.

I'm not too familiar with VCIX, so I'm not sure if there are any natural groupings. One way to tell is to look at your implementations of VCIX and see if there are any groupings. In the case here, it looks like you are giving every instruction the same behavior (for each LMUL). This leads me to believe that we may be able to start off with just one scheduler class per LMUL until someone speaks up and says they have an implementation that requires us to split into finer grained classes.

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


More information about the llvm-commits mailing list