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

[Lin Wang 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
----------------
MrLinWang wrote:

Thanks for the suggestion! After checking the scheduler queue and looking at the actual uArch design (from [Kunminghu Source](https://github.com/OpenXiangShan/XiangShan/blob/kunminghu-v2/src/main/scala/xiangshan/Parameters.scala) and [Kunminghu Block Diagram](https://docs.xiangshan.cc/projects/user-guide/en/latest/processor/)), I think the mapping could look like this, where ALU and BJU share the same queue:
```
let BufferSize = 24 in {
  // IQ0: ALU0 (ALU/MUL/BKU) + BJU0 (BRU/JMP)
  def XSPipeIntIQ0 : ProcResource<2>;
  // IQ1: ALU1 (ALU/MUL/BKU) + BJU1 (BRU/JMP)
  def XSPipeIntIQ1 : ProcResource<2>;
  // IQ2: ALU2 (ALU) + BJU2 (BRU/JMP/I2F/VSet)
  def XSPipeIntIQ2 : ProcResource<2>;
  // IQ3: ALU3 (ALU) + BJU3 (CSR/Fence/DIV)
  def XSPipeIntIQ3 : ProcResource<2>;
}
```
It seems to match the uArch better (ALU0 + BJU0, ALU1 + BJU1, etc.). What do you think about this approach?  Appreciate your feedback!

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