[RISCV] Adopt SpacemitX60's scheduling model for -mtune=generic

llvm/docs/RISCVUsage.rst

@@ -604,3 +604,16 @@ Clang's ``-msmall-data-limit=`` option controls what the threshold size is (in b
 The small data limit threshold is also used to separate small constants into sections with names starting with ``.srodata``. LLD does not place these with the ``.sdata`` and ``.sbss`` sections as ``.srodata`` sections are read only and the other two are writable. Instead the ``.srodata`` sections are placed adjacent to ``.rodata``.
 
 Data suggests that these options can produce significant improvements across a range of benchmarks.
+
+Scheduling Model and Tuning
+===========================
+
+RISC-V is highly configurable, meaning its scheduling models could be highly diversified as well. Yet we still believe it is helpful to provide a "generic" tuning processor / scheduling model that represents the "lowest common denominator" RISC-V implementation at the time. The idea is that it could serve as a "good-enough" baseline model for performance tuning purposes on some of the most common use cases.
+
+Though details of this generic scheduling model might evolve over time, we always have some _expectations_ on the kind of processors it is used for.
+
+For example, the ``generic`` tuning processor is expected to target in-order, superscalar application processors designed for general-purpose computing. It is usually RVA22U64- or RVA23U64-capable intended to run Linux. The ``generic-ooo`` has a similar set of expectations, except it is targeting out-of-order application processors.
+
+Right now, we simply assign a scheduling model that is widely used by the community to ``generic``. But in the future, we can create a standalone scheduling model for ``generic``, or even create a generic model for each of the individual sectors. For example, a ``generic-embedded`` for embedded processors and a ``generic-server`` for server workloads.
+
+These future generic models could even serve as the "base" model for other scheduling models to derive from: it's not uncommon for multiple processors to share a similar set of instruction scheduling info except a few key instructions, and this is especially true for RISC-V given its highly configurable nature. If we could design the base model in a way that it can be _parameterized_ by subtarget tuning features, we can substitue the traditional way of creating individual scheduling models with a combination of base scheduling model + different subtarget features.

llvm/docs/ReleaseNotes.md

@@ -149,6 +149,7 @@ Changes to the RISC-V Backend
 * Adds experimental support for the 'Zibi` (Branch with Immediate) extension.
 * Add support for Zvfofp8min (OFP8 conversion extension)
 * Adds assembler support for the Andes `XAndesvsinth` (Andes Vector Small Int Handling Extension).
+* `-mtune=generic` now uses the scheduling model from SpacemitX60 instead of an empty scheduling model.
 
 Changes to the WebAssembly Backend
 ----------------------------------

llvm/lib/Target/RISCV/RISCVProcessors.td

@@ -88,21 +88,25 @@ class RISCVTuneProcessorModel<string n,
 
 defvar GenericTuneFeatures = [TuneOptimizedNF2SegmentLoadStore];
 
+// `generic-rv32`, and `generic-rv64` are expected to target
+// in-order application processors designed for general-purpose computing.
 def GENERIC_RV32 : RISCVProcessorModel<"generic-rv32",
-                                       NoSchedModel,
+                                       SpacemitX60Model,
                                        [Feature32Bit,
                                         FeatureStdExtI],
                                        GenericTuneFeatures>,
                    GenericTuneInfo;
 def GENERIC_RV64 : RISCVProcessorModel<"generic-rv64",
-                                       NoSchedModel,
+                                       SpacemitX60Model,
                                        [Feature64Bit,
                                         FeatureStdExtI],
                                        GenericTuneFeatures>,
                    GenericTuneInfo;
 // Support generic for compatibility with other targets. The triple will be used
 // to change to the appropriate rv32/rv64 version.
 def GENERIC : RISCVTuneProcessorModel<"generic", NoSchedModel>, GenericTuneInfo;
+// `generic-ooo` is expected to target out-of-order application processors designed
+// for general-purpose computing.
 def GENERIC_OOO : RISCVTuneProcessorModel<"generic-ooo", GenericOOOModel>,
                   GenericTuneInfo;
 

llvm/test/CodeGen/RISCV/GlobalISel/add-imm.ll

@@ -170,16 +170,16 @@ define signext i32 @add32_sext_accept(i32 signext %a) nounwind {
 define signext i32 @add32_sext_reject_on_rv64(i32 signext %a) nounwind {
 ; RV32I-LABEL: add32_sext_reject_on_rv64:
 ; RV32I:       # %bb.0:
-; RV32I-NEXT:    lui a1, %hi(gv0)
 ; RV32I-NEXT:    addi a0, a0, 2047
+; RV32I-NEXT:    lui a1, %hi(gv0)
 ; RV32I-NEXT:    addi a0, a0, 953
 ; RV32I-NEXT:    sw a0, %lo(gv0)(a1)
 ; RV32I-NEXT:    ret
 ;
 ; RV64I-LABEL: add32_sext_reject_on_rv64:
 ; RV64I:       # %bb.0:
-; RV64I-NEXT:    lui a1, %hi(gv0)
 ; RV64I-NEXT:    addi a0, a0, 2047
+; RV64I-NEXT:    lui a1, %hi(gv0)
 ; RV64I-NEXT:    addiw a0, a0, 953
 ; RV64I-NEXT:    sw a0, %lo(gv0)(a1)
 ; RV64I-NEXT:    ret

llvm/test/CodeGen/RISCV/GlobalISel/alu-roundtrip.ll

@@ -438,11 +438,10 @@ entry:
 define i64 @sub_i64(i64 %a, i64 %b) {
 ; RV32IM-LABEL: sub_i64:
 ; RV32IM:       # %bb.0: # %entry
-; RV32IM-NEXT:    sub a4, a0, a2
-; RV32IM-NEXT:    sltu a0, a0, a2
+; RV32IM-NEXT:    sltu a4, a0, a2
 ; RV32IM-NEXT:    sub a1, a1, a3
-; RV32IM-NEXT:    sub a1, a1, a0
-; RV32IM-NEXT:    mv a0, a4
+; RV32IM-NEXT:    sub a0, a0, a2
+; RV32IM-NEXT:    sub a1, a1, a4
 ; RV32IM-NEXT:    ret
 ;
 ; RV64IM-LABEL: sub_i64:
@@ -479,11 +478,10 @@ entry:
 define i64 @neg_i64(i64 %a) {
 ; RV32IM-LABEL: neg_i64:
 ; RV32IM:       # %bb.0: # %entry
-; RV32IM-NEXT:    neg a2, a0
-; RV32IM-NEXT:    snez a0, a0
+; RV32IM-NEXT:    snez a2, a0
 ; RV32IM-NEXT:    neg a1, a1
-; RV32IM-NEXT:    sub a1, a1, a0
-; RV32IM-NEXT:    mv a0, a2
+; RV32IM-NEXT:    neg a0, a0
+; RV32IM-NEXT:    sub a1, a1, a2
 ; RV32IM-NEXT:    ret
 ;
 ; RV64IM-LABEL: neg_i64:
@@ -594,13 +592,12 @@ entry:
 define i64 @mul_i64(i64 %a, i64 %b) {
 ; RV32IM-LABEL: mul_i64:
 ; RV32IM:       # %bb.0: # %entry
-; RV32IM-NEXT:    mul a4, a0, a2
 ; RV32IM-NEXT:    mul a1, a1, a2
 ; RV32IM-NEXT:    mul a3, a0, a3
-; RV32IM-NEXT:    mulhu a0, a0, a2
+; RV32IM-NEXT:    mulhu a4, a0, a2
+; RV32IM-NEXT:    mul a0, a0, a2
 ; RV32IM-NEXT:    add a1, a1, a3
-; RV32IM-NEXT:    add a1, a1, a0
-; RV32IM-NEXT:    mv a0, a4
+; RV32IM-NEXT:    add a1, a1, a4
 ; RV32IM-NEXT:    ret
 ;
 ; RV64IM-LABEL: mul_i64: