[RISCV] Make Latency/ResourceCycles relevant to LMUL

[wangpc]

Summary

When modeling vector WriteRes, there are some fields that we can
specify to model its costs like Latency, ResourceCycles, etc.

For Latency, it may not be relevant to LMUL with mechanisms like
chaining[1].

But for ResourceCycles, it may be different. The cycles of some
resources can be relevant to LMUL. For example, the generation and
issuing of uops.

In this patch, we add two new template parameter latency and
resourceCycles. The latency is a function that accepts LMUL and
SEW and returns cycles. The resourceCycles is a list of such
function, each presents the cycles of resource.

We provide pre-defined function fixed that returns a function who
returns fixed-value to model latency/resources which are not relevant
to LMULs. User may definde their own functions according to their
processor model.

References:
[1] Chaining (vector processing)

[michaelmaitland]

One concern I have is that a microarchitecture may wish to have more flexibility over the number of resource cycles for each LMUL than the multiplier subroutine allows for. I am imagining a scenario where the number of resource cycles for different LMUL is more complex than multiplication by the LMUL factor. Something like this would allow for maximum flexibility:

for mx in MxList {
  defvar RC = ...; // Something that may be more complex than BaseCycles * multiplier
  defvar L = ...; // Maybe latency is still relevant, even if it is less important than ResourceCycles
  let ResourceCycles = [RC], Latency = L in {
    ...
  }
}

[• pcwang-thead]

In D146198#4199432, @michaelmaitland wrote:

One concern I have is that a microarchitecture may wish to have more flexibility over the number of resource cycles for each LMUL than the multiplier subroutine allows for. I am imagining a scenario where the number of resource cycles for different LMUL is more complex than multiplication by the LMUL factor. Something like this would allow for maximum flexibility:

for mx in MxList {
  defvar RC = ...; // Something that may be more complex than BaseCycles * multiplier
  defvar L = ...; // Maybe latency is still relevant, even if it is less important than ResourceCycles
  let ResourceCycles = [RC], Latency = L in {
    ...
  }
}

Yes, I wanted it to be flexible as what you described.
But for Latency and ResourceCycles, both of them are TableGen compile-time constants (of course we can override them via some target hooks, but it is off the table), so there is no way to specify them as custom handling code.
I tried to model them as something like below:

1. We pass subroutines to LMULWriteResImpl in RISCVSchedule.td

multiclass LMULWriteResImpl<string name, list<ProcResourceKind> resources,
                            LatencySubroutine latencySubroutine,
                            list<ResourceCycleSubroutine> resourceCycleSubroutines>{
  for mx in MxList {
    defvar RC = apply resourceCycleSubroutines to mx; // It acts like calling these subroutines.
    defvar L =apply latencySubroutine to mx; // Same as above.
    let ResourceCycles = [RC], Latency = L in {
      ...
    }
  }
}

2. We define these subroutines in custom scheduling model RISCVSchedXXX.td

class CustomSubroutine1<string mx> {
  list<int> ResourceCycles = ...; // Custom handling of different LMULs.
}
class CustomSubroutine2<string mx>{
......
}
……

But for TableGen, we can't pass functions since it is a template description language, so we can't achieve something like this (if I understand TableGen correctly). So I think we may define some pre-defined subroutines like fixed, multiplier and so on in RISCVScheduleV.td, and then users can use them in their scheduling models. If there are some microarchitectures that can't be modeled, just add a new subroutine to upstream if approved.

[michaelmaitland]

If there are some microarchitectures that can't be modeled, just add a new subroutine to upstream if approved.

Does this mean that subtarget routines must be added to the RISCVScheduleV file since the following function needs to know about the custom subroutine to do its isa checks:

// Helper class for generating a list of resource cycles of different LMULs.
class ResourceCycles<list<ResourceCycle> resourceCycles, string mx> {

I am concerned that the RISCVScheduleV file will take on bloat due to holding subtarget related routines if this is the case.

[• pcwang-thead]

In D146198#4202168, @michaelmaitland wrote:

If there are some microarchitectures that can't be modeled, just add a new subroutine to upstream if approved.

Does this mean that subtarget routines must be added to the RISCVScheduleV file since the following function needs to know about the custom subroutine to do its isa checks:

// Helper class for generating a list of resource cycles of different LMULs.
class ResourceCycles<list<ResourceCycle> resourceCycles, string mx> {

I am concerned that the RISCVScheduleV file will take on bloat due to holding subtarget related routines if this is the case.

Yes. So I posted this patch here just to discuss how we should handle this.
For example, solutions may be:

1. Add routines to RISCVScheduleV.td just as what I have done.
2. Extend TableGen to support pass functions:

// Supposes that we have a Function class to present a function object that its parameters are function parameters.
class TargetSubroutine<int base, string mx> : Function;

// Then. Supposes that we have a new bang operator to apply this function to input parameters and the result is `ret`.
class ResourceCycles<list<TargetSubroutine> subroutines, int base, string mx> {
  list<int> value = !foreach(subroutine, subroutines,
                             !apply(subroutine, base, mx)
                            );
}

// In SchedXXX.td, we can define our own routines.
class Multiplier<int base, string mx>:TargetSubroutine {
 // We return an int value calculated from mx.
 int ret = !mul(base, multiplier<mx>.value);
}

3. Some templates are flexible to specify cycles according to LMULs (I haven't figured out one...).

[michaelmaitland]

In D146198#4205441, @pcwang-thead wrote:

In D146198#4202168, @michaelmaitland wrote:

If there are some microarchitectures that can't be modeled, just add a new subroutine to upstream if approved.

Does this mean that subtarget routines must be added to the RISCVScheduleV file since the following function needs to know about the custom subroutine to do its isa checks:

// Helper class for generating a list of resource cycles of different LMULs.
class ResourceCycles<list<ResourceCycle> resourceCycles, string mx> {

I am concerned that the RISCVScheduleV file will take on bloat due to holding subtarget related routines if this is the case.

Yes. So I posted this patch here just to discuss how we should handle this.
For example, solutions may be:

1. Add routines to RISCVScheduleV.td just as what I have done.
2. Extend TableGen to support pass functions:

// Supposes that we have a Function class to present a function object that its parameters are function parameters.
class TargetSubroutine<int base, string mx> : Function;

// Then. Supposes that we have a new bang operator to apply this function to input parameters and the result is `ret`.
class ResourceCycles<list<TargetSubroutine> subroutines, int base, string mx> {
  list<int> value = !foreach(subroutine, subroutines,
                             !apply(subroutine, base, mx)
                            );
}

// In SchedXXX.td, we can define our own routines.
class Multiplier<int base, string mx>:TargetSubroutine {
 // We return an int value calculated from mx.
 int ret = !mul(base, multiplier<mx>.value);
}

3. Some templates are flexible to specify cycles according to LMULs (I haven't figured out one...).

What stops us from doing something like this:
https://github.com/llvm/llvm-project/blob/0c0468e6df2bcabd207858891c2387357857b0bc/llvm/lib/Target/SystemZ/SystemZScheduleZ13.td#L95https://github.com/llvm/llvm-project/blob/0c0468e6df2bcabd207858891c2387357857b0bc/llvm/lib/Target/SystemZ/SystemZScheduleZ13.td#L95
or
https://github.com/llvm/llvm-project/blob/0c0468e6df2bcabd207858891c2387357857b0bc/llvm/lib/Target/AMDGPU/SISchedule.td#L160
?

Num or 2 could be replaced with something like MyTargetGetCycles<mx>.c without needing to extend the tablegen language. For example in the SchedXXX.td file:

class MyTargetGetCycles<string mx> {
  int c = !cond(
    !eq(mx, "M1") : 1,
    !eq(mx, "M2") : 1,
    !eq(mx, "M4") : 1,
    !eq(mx, "M8") : 1,
    !eq(mx, "MF2") : 1,
    !eq(mx, "MF4") : 1,
    !eq(mx, "MF8") : 1,
    !eq(mx, "UpperBound") : 1
  );
}

foreach mx = SchedMxList in {
  defvar Cycles = MyTargetGetCycles<mx>.c;
  let Latency = Cycles, ResourceCycles = [Cycles] in {
    defm "" : LMULWriteResMX<"WriteVLDE",   [MyTargetSomeResource], mx>;
    defm "" : LMULWriteResMX<"WriteVSTE",   [MyTargetSomeResource], mx>;
  }
}

[• pcwang-thead]

In D146198#4206929, @michaelmaitland wrote:

In D146198#4205441, @pcwang-thead wrote:

In D146198#4202168, @michaelmaitland wrote:

If there are some microarchitectures that can't be modeled, just add a new subroutine to upstream if approved.

Does this mean that subtarget routines must be added to the RISCVScheduleV file since the following function needs to know about the custom subroutine to do its isa checks:

// Helper class for generating a list of resource cycles of different LMULs.
class ResourceCycles<list<ResourceCycle> resourceCycles, string mx> {

I am concerned that the RISCVScheduleV file will take on bloat due to holding subtarget related routines if this is the case.

Yes. So I posted this patch here just to discuss how we should handle this.
For example, solutions may be:

1. Add routines to RISCVScheduleV.td just as what I have done.
2. Extend TableGen to support pass functions:

// Supposes that we have a Function class to present a function object that its parameters are function parameters.
class TargetSubroutine<int base, string mx> : Function;

// Then. Supposes that we have a new bang operator to apply this function to input parameters and the result is `ret`.
class ResourceCycles<list<TargetSubroutine> subroutines, int base, string mx> {
  list<int> value = !foreach(subroutine, subroutines,
                             !apply(subroutine, base, mx)
                            );
}

// In SchedXXX.td, we can define our own routines.
class Multiplier<int base, string mx>:TargetSubroutine {
 // We return an int value calculated from mx.
 int ret = !mul(base, multiplier<mx>.value);
}

3. Some templates are flexible to specify cycles according to LMULs (I haven't figured out one...).

What stops us from doing something like this:
https://github.com/llvm/llvm-project/blob/0c0468e6df2bcabd207858891c2387357857b0bc/llvm/lib/Target/SystemZ/SystemZScheduleZ13.td#L95https://github.com/llvm/llvm-project/blob/0c0468e6df2bcabd207858891c2387357857b0bc/llvm/lib/Target/SystemZ/SystemZScheduleZ13.td#L95
or
https://github.com/llvm/llvm-project/blob/0c0468e6df2bcabd207858891c2387357857b0bc/llvm/lib/Target/AMDGPU/SISchedule.td#L160
?

Num or 2 could be replaced with something like MyTargetGetCycles<mx>.c without needing to extend the tablegen language. For example in the SchedXXX.td file:

class MyTargetGetCycles<string mx> {
  int c = !cond(
    !eq(mx, "M1") : 1,
    !eq(mx, "M2") : 1,
    !eq(mx, "M4") : 1,
    !eq(mx, "M8") : 1,
    !eq(mx, "MF2") : 1,
    !eq(mx, "MF4") : 1,
    !eq(mx, "MF8") : 1,
    !eq(mx, "UpperBound") : 1
  );
}

foreach mx = SchedMxList in {
  defvar Cycles = MyTargetGetCycles<mx>.c;
  let Latency = Cycles, ResourceCycles = [Cycles] in {
    defm "" : LMULWriteResMX<"WriteVLDE",   [MyTargetSomeResource], mx>;
    defm "" : LMULWriteResMX<"WriteVSTE",   [MyTargetSomeResource], mx>;
  }
}

That's because LMULWriteRes is already LMUL-relevant and we have looped SchedMxList in LMULWriteResImpl. If we loop it again, the result would be weird.
Another approach is to define something like LMULWriteResImpl in SchedXXX.td and override Latency and ResourceCycles according to LMUL. But if so, why bother to define some boilerplates like LMULWriteRes in RISCVScheduleV.td?

[michaelmaitland]

Then yea, I think (2) is probably the approach that feels most natural to me.

[michaelmaitland]

This comment was removed by michaelmaitland.

[craig.topper]

Why can't ResourceCycles be the base class that just contains a list of integers. Other classes inherit that and construct the list however they want. A fixed class could take a cycle count and put that value in every entry in the list. The lmul scaled class could take an cycle and mutliply.

[• pcwang-thead]

In D146198#4231514, @craig.topper wrote:

Why can't ResourceCycles be the base class that just contains a list of integers. Other classes inherit that and construct the list however they want. A fixed class could take a cycle count and put that value in every entry in the list. The lmul scaled class could take an cycle and mutliply.

I think the reason is that we need LMUL info to generate the list but we can't get it in SchedXXX.td.
We had a complex implementation which seems to be likely what you described(if I understand correctly), I will upload it later. :-)

[craig.topper]

In D146198#4232590, @pcwang-thead wrote:

In D146198#4231514, @craig.topper wrote:

Why can't ResourceCycles be the base class that just contains a list of integers. Other classes inherit that and construct the list however they want. A fixed class could take a cycle count and put that value in every entry in the list. The lmul scaled class could take an cycle and mutliply.

I think the reason is that we need LMUL info to generate the list but we can't get it in SchedXXX.td.
We had a complex implementation which seems to be likely what you described(if I understand correctly), I will upload it later. :-)

Why do we need LMUL info?

We can have a class that contains an 8 entry list of resource cycles for each LMUL plus upper bound. We can have derived classes that construct this list based on common cases.

LMULWriteResImpl can index into the list to the entry corresponding to the LMUL. Nothing in RISCVScedule.td needs to know how the list was constructed.

[• pcwang-thead]

In D146198#4232662, @craig.topper wrote:

In D146198#4232590, @pcwang-thead wrote:

In D146198#4231514, @craig.topper wrote:

Why can't ResourceCycles be the base class that just contains a list of integers. Other classes inherit that and construct the list however they want. A fixed class could take a cycle count and put that value in every entry in the list. The lmul scaled class could take an cycle and mutliply.

I think the reason is that we need LMUL info to generate the list but we can't get it in SchedXXX.td.
We had a complex implementation which seems to be likely what you described(if I understand correctly), I will upload it later. :-)

Why do we need LMUL info?

We can have a class that contains an 8 entry list of resource cycles for each LMUL plus upper bound. We can have derived classes that construct this list based on common cases.

LMULWriteResImpl can index into the list to the entry corresponding to the LMUL. Nothing in RISCVScedule.td needs to know how the list was constructed.

Oh I get it. The key point is that we can't index list by dynamic index(?), the index can only be constant:

[build] llvm/lib/Target/RISCV/RISCVScheduleV.td:63:82: error: Variable not defined: 'i'
[build]   defvar i = IndexOfLMUL<mx>.value;
[build]   list<int> value = !foreach(resourceCycle, resourceCycles, resourceCycle.Cycles[i]);
                                                                                         ^

---

OK, I just know how to do it.

[• pcwang-thead]

• Rebase.
• Apply @craig.topper 's suggestion. Thanks a lot!

[• pcwang-thead]

@craig.topper Is this what you suggest? It seems to be OK for cases where only LMUL is taken into consideration. But when both SEW and LMUL are accounted for, would it be too complicated to generate two-dimension lists?

[• pcwang-thead]

• Fix errors.
• Rename index to IndexByLMUL.
• Support WorstCase.

[• pcwang-thead]

• Rebase.
• Use function.

[michaelmaitland]

LGTM.

llvm/lib/Target/RISCV/RISCVScheduleV.td

75

When we call latency("WorstCase") and resourceCycle("WorstCase"), we're treating WorstCase as an LMUL value since we're passing it as the parameter that is used to pass LMUL. The last few changes to this file have aimed to move away from this by trying to have WorstCase mean worst case SchedWrite, not mean worst case LMUL.

We still need to get the Latency and ResourceCycles for the worst case WriteRes though, and it would make sense to get it from this list. I thought about a solution where we pass a boolean parameter which signifies to return the WorstCase value:

function MyCyclesFunc() : function<bit, int, string, int> {
  return function(bit isWorstCase, string lmul = M1, int sew = 0,): int {
    return !if(isWorstCase : 10, !cond( /* return the lmul&sew cycles */);
  };
}

However, calling latency(true) feels worst than calling latency("WorstCase"). It also makes the body of the lambda messier. As a result, I am willing to concede to passing WorstCase` to these functions as the LMUL parameter. Curious if anyone has any input here.

llvm/lib/Target/RISCV/RISCVScheduleV.td

list<int> val = !cond(!eq(mx, "M1"):  [8, 16, 32, 64],
                         !eq(mx, "M2"):  [8, 16, 32, 64],
                         !eq(mx, "M4"):  [8, 16, 32, 64],
                         !eq(mx, "M8"):  [8, 16, 32, 64],
                         !eq(mx, "MF2"): [8, 16, 32],
                         !eq(mx, "MF4"): [8, 16],
                         !eq(mx, "MF8"): [8]);
 }
 
+// Index values by LMUL.
+class IndexByLMUL<list<int> cycles, string mx> {
+  int value = !cond(!eq(mx, "M1")        : cycles[0],
+                    !eq(mx, "M2")        : cycles[1],
+                    !eq(mx, "M4")        : cycles[2],
+                    !eq(mx, "M8")        : cycles[3],
+                    !eq(mx, "MF2")       : cycles[4],
+                    !eq(mx, "MF4")       : cycles[5],
+                    !eq(mx, "MF8")       : cycles[6],
+                    !eq(mx, "WorstCase") : cycles[7],);
+}
+
+class ResourceCycle {
+  list<int> Cycles;
+}
+// ResourceCycle whose cycles are fixed.
+class FixedResourceCycle<int cycles> : ResourceCycle {
+  let Cycles = !listsplat(cycles, !add(!size(SchedMxList), 1));
+}
+
+// Helper class for generating a list of resource cycles of different LMULs.
+class ResourceCycles<list<ResourceCycle> resourceCycles, string mx> {
+  list<int> value = !foreach(resourceCycle, resourceCycles,
+                             IndexByLMUL<resourceCycle.Cycles, mx>.value);
+}
+
 // Define multiclasses to define SchedWrite, SchedRead,  WriteRes, and
 // ReadAdvance for each (name, LMUL) pair and for each LMUL in each of the
 // SchedMxList variants above. Each multiclass is responsible for defining
 // a record that represents the WorseCase behavior for name.
 multiclass LMULSchedWritesImpl<string name, list<string> MxList> {
   def name # "_WorstCase" : SchedWrite;
   foreach mx = MxList in {
     def name # "_" # mx : SchedWrite;
   }
 }
 multiclass LMULSchedReadsImpl<string name, list<string> MxList> {
   def name # "_WorstCase" : SchedRead;
   foreach mx = MxList in {
     def name # "_" # mx : SchedRead;
   }
 }
-multiclass LMULWriteResImpl<string name, list<ProcResourceKind> resources> {
+multiclass LMULWriteResImpl<string name, list<ProcResourceKind> resources,
+                            ResourceCycle latency, list<ResourceCycle> resourceCycles> {
   if !exists<SchedWrite>(name # "_WorstCase") then
-    def : WriteRes<!cast<SchedWrite>(name # "_WorstCase"), resources>;
+    def : WriteRes<!cast<SchedWrite>(name # "_WorstCase"), resources> {
+      let Latency = IndexByLMUL<latency.Cycles, "WorstCase">.value;
+      let ResourceCycles = ResourceCycles<resourceCycles, "WorstCase">.value;
+    }
   foreach mx = SchedMxList in {
     if !exists<SchedWrite>(name # "_" # mx) then
-      def : WriteRes<!cast<SchedWrite>(name # "_" # mx), resources>;
+      def : WriteRes<!cast<SchedWrite>(name # "_" # mx), resources> {
+        let Latency = IndexByLMUL<latency.Cycles, mx>.value;
+        let ResourceCycles = ResourceCycles<resourceCycles, mx>.value;
+      }
   }
 }
 multiclass LMULReadAdvanceImpl<string name, int val,
                                list<SchedWrite> writes = []> {
   if !exists<SchedRead>(name # "_WorstCase") then
     def : ReadAdvance<!cast<SchedRead>(name # "_WorstCase"), val, writes>;
   foreach mx = SchedMxList in {
     if !exists<SchedRead>(name # "_" # mx) then
class LMULSchedWriteListImpl<list<string> names, list<string> MxList> {
   list<SchedWrite> value = !foldl([]<SchedWrite>,
                                   !foreach(name, names,
                                     !foreach(mx, MxList, !cast<SchedWrite>(name # "_" # mx))),
                                   all, writes, !listconcat(all, writes));
 }
 
 multiclass LMULSchedWrites<string name> : LMULSchedWritesImpl<name, SchedMxList>;
 multiclass LMULSchedReads<string name> : LMULSchedReadsImpl<name, SchedMxList>;
-multiclass LMULWriteRes<string name, list<ProcResourceKind> resources>
-  : LMULWriteResImpl<name, resources>;
+multiclass LMULWriteRes<string name, list<ProcResourceKind> resources,
+                        ResourceCycle latency = FixedResourceCycle<1>,
+                        list<ResourceCycle> resourceCycles = []>
+  : LMULWriteResImpl<name, resources, latency, resourceCycles>;
 multiclass LMULReadAdvance<string name, int val, list<SchedWrite> writes = []>
   : LMULReadAdvanceImpl<name, val, writes>;
 class LMULSchedWriteList<list<string> names> : LMULSchedWriteListImpl<names, SchedMxList>;
 
 multiclass LMULSEWSchedWrites<string name> : LMULSEWSchedWritesImpl<name, SchedMxList>;
 multiclass LMULSEWSchedReads<string name> : LMULSEWSchedReadsImpl<name, SchedMxList>;
 multiclass LMULSEWWriteRes<string name, list<ProcResourceKind> resources>
   : LMULSEWWriteResImpl<name, resources>;
 multiclass LMULSEWReadAdvance<string name, int val, list<SchedWrite> writes = []>
   : LMULSEWReadAdvanceImpl<name, val, writes>;
 
 multiclass LMULSchedWritesW<string name> : LMULSchedWritesImpl<name, SchedMxListW>;
 multiclass LMULSchedReadsW<string name> : LMULSchedReadsImpl<name, SchedMxListW>;
-multiclass LMULWriteResW<string name, list<ProcResourceKind> resources>
-  : LMULWriteResImpl<name, resources>;
+multiclass LMULWriteResW<string name, list<ProcResourceKind> resources,
+                         ResourceCycle latency = FixedResourceCycle<1>,
+                         list<ResourceCycle> resourceCycles = []>
+  : LMULWriteResImpl<name, resources, latency, resourceCycles>;
 multiclass LMULReadAdvanceW<string name, int val, list<SchedWrite> writes = []>
   : LMULReadAdvanceImpl<name, val, writes>;
 class LMULSchedWriteListW<list<string> names> : LMULSchedWriteListImpl<names, SchedMxListW>;
 
 multiclass LMULSchedWritesFW<string name> : LMULSchedWritesImpl<name, SchedMxListFW>;
 multiclass LMULSchedReadsFW<string name> : LMULSchedReadsImpl<name, SchedMxListFW>;
-multiclass LMULWriteResFW<string name, list<ProcResourceKind> resources>
-  : LMULWriteResImpl<name, resources>;
+multiclass LMULWriteResFW<string name, list<ProcResourceKind> resources,
+                          ResourceCycle latency = FixedResourceCycle<1>,
+                          list<ResourceCycle> resourceCycles = []>
+  : LMULWriteResImpl<name, resources, latency, resourceCycles>;
 multiclass LMULReadAdvanceFW<string name, int val, list<SchedWrite> writes = []>
   : LMULReadAdvanceImpl<name, val, writes>;
 class LMULSchedWriteListFW<list<string> names> : LMULSchedWriteListImpl<names, SchedMxListFW>;
 
 multiclass LMULSchedWritesFWRed<string name> : LMULSchedWritesImpl<name, SchedMxListFWRed>;
-multiclass LMULWriteResFWRed<string name, list<ProcResourceKind> resources>
-  : LMULWriteResImpl<name, resources>;
+multiclass LMULWriteResFWRed<string name, list<ProcResourceKind> resources,
+                             ResourceCycle latency = FixedResourceCycle<1>,
+                             list<ResourceCycle> resourceCycles = []>
+  : LMULWriteResImpl<name, resources, latency, resourceCycles>;
 class LMULSchedWriteListFWRed<list<string> names> : LMULSchedWriteListImpl<names, SchedMxListFWRed>;
 
 
 // 3.6 Vector Byte Length vlenb
 def WriteRdVLENB      : SchedWrite;
 
 // 6. Configuration-Setting Instructions
 def WriteVSETVLI      : SchedWrite;