[llvm] [RISCV] Add scheduler definitions for XiangShan-KunMingHu (PR #148581)

[Min-Yih Hsu via llvm-commits]

================
@@ -0,0 +1,357 @@
+//==- RISCVSchedXiangShanKunMingHu.td - XiangShanKunMingHu Scheduling Defs -*- tablegen -*-=//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// The XiangShan is a high-performance open-source RISC-V processor project 
+// initiated by the Institute of Computing Technology(ICT), Chinese Academy of Sciences(CAS). 
+// The KunMingHu architecture is its third-generation derivative, 
+// developed by the Institute of Computing Technology, Chinese Academy of Sciences  
+// and the Beijing Institute of Open Source Chip (BOSC), 
+// with a focus on achieving higher performance.
+// Source: https://github.com/OpenXiangShan/XiangShan
+// Documentation: https://docs.xiangshan.cc/projects/design/en/latest/
+// User Guide: https://docs.xiangshan.cc/projects/user-guide/en/latest/
+
+def XiangShanKunMingHuModel : SchedMachineModel {
+  let IssueWidth = 6;   // 6-way decode and dispatch
+  let MicroOpBufferSize = 256;
+  let LoopMicroOpBufferSize = 48;  // Instruction queue size
+  let LoadLatency = 6;
+  let MispredictPenalty = 13; // Based on estimate of pipeline depth.
+  let CompleteModel = 0;
+  let UnsupportedFeatures = [HasStdExtZcmt, HasStdExtZkr, HasVInstructions,
+                             HasVInstructionsI64];
+}
+
+let SchedModel = XiangShanKunMingHuModel in {
+// Define each kind of processor resource and number available.
+/// Pipline
+let BufferSize = 24 in {
+  // Integer
+  def XSPipeALU0 : ProcResource<1>; // ALU, MUL, BKU
+  def XSPipeALU1 : ProcResource<1>; // ALU, MUL, BKU
+  def XSPipeALU2 : ProcResource<1>; // ALU
+  def XSPipeALU3 : ProcResource<1>; // ALU
----------------
mshockwave wrote:

I must have misunderstood the diagram previously: indeed, ALU0 and BJU0 should share the same buffer rather than ALU0 and ALU1.

That being said, it's still a bit problematic if we "merge" ALU0 and BJU0 into the same ProcResource, because ALU0 and BJU0 do not handle the same kinds of instructions. Instead, I think we can keep the current `XSPipeALU<N>` and `XSPipeBJU<N>` declarations and add an additional:
```
let BufferSize = 24 in {
  def XSPipeIntIQ0 : ProcResGroup<[XSPipeALU0, XSPipeBJU0]>;
  def XSPipeIntIQ1 : ProcResGroup<[XSPipeALU1, XSPipeBJU1]>;
  ...
}
```
Note that even with the new ProcResGroup above, you should still keep the `XSPipeGroupALU`, `XSPipeGroupBKU` etc. below.

The idea is that groups like `XSPipeGroupALU` is for issuing -- pipes in this group can handle the same set of instructions so we can easily attach `XSPipeGroupALU` on those instructions' `WriteRes`. While `XSPipeIntIQ0` is more like created specifically for tracking buffer consumption (only in llvm-mca of course, as machine scheduler doesn't even use the BufferSize). Though `XSPipeIntIQ0` will not be attached to any `WriteRes`, any `WriteRes` that consume resources like `XSPipeALU0` or  `XSPipeGroupALU` will also _implicitly_ consume `XSPipeIntIQ0` since `XSPipeALU0` is a member of `XSPipeIntIQ0`. 

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