[llvm] [AArch64] SME definitions for C1-Ultra scheduling model (PR #194850)

[David Green via llvm-commits]

================
@@ -93,60 +115,248 @@ def : WriteRes<WriteLDHi,    []> { let Latency = 4; }
 // Define customized scheduler read/write types specific to C1 Ultra.
 //===----------------------------------------------------------------------===//
 
-// Define generic 0 micro-op types.
+// The approach for modelling SME instructions should not be taken as accurate.
+// This is due to limitations of tablegen and the actual behaviour we want to
+// to model. The CME is a co-processor. Accurate modelling would allow for us
+// to model core-to-processor communication latencies. This is out of the scope
+// of what we can achieve at the present. As a consequence we model instructions
+// that run on the CME as by only modelling their execution latency once issued
+// rather than modelling the more complex relationship between the C1-Ultra and
+// the CME co-processor and how that will affect execution latencies. Developers
+// must therefore take latencies for SME instructions as inaccurate.
+//
+// We have several classes of SME instructions that we need to model.
+//
+//    1. SVE instructions added by SME and available when not in streaming SVE mode
+//    2. SVE instructions added by SME but not sent to CME when in streaming SVE mode
+//    3. FP/SVE/ASIMD instructions sent to CME when in streaming SVE mode
+//    4. SME instructions sent to CME and only available in streaming SVE mode
+//
+// To model instructions of type (1) and (2) is fairly easy in that we know
+// that these instructions aren't "dependent" on streaming SVE mode to model their
+// scheduling information. To model these we use a predicate on these instructions
+// which checks if the target supports SME (SMESchedPred).
+//
+// To model instructions of type (3) we recognise that llvm-mca doesn't include
+// information of whether we are in streaming SVE mode. However, for the sake of
+// completeness we model this class of instructions by adding
+// an llvm-mca attribute (mca-streaming-sched) which is interpreted as the core
+// being in streaming SVE mode. This allows us to at least have some data on how
+// these instructions may be scheduled when in streaming SVE mode using llvm-mca
+// if the core supports SME and this attribute is enabled. Otherwise, we default
+// to the plain non-streaming SVE mode scheduling information.
+//
+// Similarly, to model instructions of type (4) we just extend the scheduling model
+// to add definitions for this class of instructions which are "gated" via the
+// SMESchedPred predicate and mca-streaming-sched attribute. The purpose of
+// having these definitions is that information on how these instructions are
+// scheduled on the CME coprocessor is useful for analysis.
+
+// SME2 related read write types
+// Define generic 0 and 1 micro-op types
 def C1UWrite_0c : SchedWriteRes<[]> { let Latency = 0; }
+def C1UWrite_1c : SchedWriteRes<[]> { let Latency = 1; }
+
+class C1UCMEWrite<int LatencyCycles, list<ProcResourceKind> Resources>
+    : SchedWriteRes<Resources> {
+  let Latency = LatencyCycles;
+}
+
+class C1UCMEWriteRC<int LatencyCycles, list<ProcResourceKind> Resources,
+                    list<int> ReleaseCycles>
+    : SchedWriteRes<Resources> {
+  let Latency = LatencyCycles;
+  let ReleaseAtCycles = ReleaseCycles;
+}
+
+class C1UStreamingSchedWrite<SchedWrite StreamingWrite, SchedWrite BaseWrite>
+    : SchedWriteVariant<[
+        SchedVar<SMEMCStreamingSchedPred, [StreamingWrite]>,
+        SchedVar<NoSchedPred,            [BaseWrite]>
+      ]>;
+
+
+// Instructions added by SME and only available in streaming SVE mode
+// For these, we return the CME write as a default even if not in streaming.
+class C1UStreamingOnlySchedWrite<SchedWrite StreamingWrite> :
+    C1UStreamingSchedWrite<StreamingWrite, StreamingWrite>;
----------------
davemgreen wrote:

Is this necessary now? IIUC it adds the extra overhead of a variant without being a variant.

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