[gcc r17-3276] [RISC-V][PR target/108031] Adjust cost of LO_SUM expression slightly

https://gcc.gnu.org/g:0cfd3de946cedafc0948fe4fde5a015c63b8993c

commit r17-3276-g0cfd3de946cedafc0948fe4fde5a015c63b8993c
Author: Jeff Law <[email protected]>
Date:   Thu Aug 13 21:22:57 2026 -0600

    [RISC-V][PR target/108031] Adjust cost of LO_SUM expression slightly
    
    So this is the second part to pr108031.
    
    Originally I thought this was going to be related to Shreya's work on fixing
    various cost model goofs in the RISC-V backend and that if we fixed the cost
    modeling that the right things would just happen.  Essentially what I've had
    her focused on is cases where we have a single cycle ALU insn, but the reported
    cost is anything but 4.  Lots of these issues have been clustered around
    embedded extensions, complex RTL for bitmanip instructions, symbolic addresses,
    etc.  I figured the costing issue with 108031 would be related.
    
    But it'd been a while since I did that very quick triage, so I went back and
    took a closer look at the behavior inside CSE; that's when it became clear that
    the LO_SUM expression and related value equivalent were reporting the same
    cost.  In that scenario CSE (reasonably) chooses to keep things as-is to avoid
    gratuitous IL changes.
    
    So we need the LO_SUM expression to cost higher than a simple PLUS, even though
    they both collapse into addi/add insns.  It's not as crazy at it might seem as
    anytime we can get rid of the LO_SUM form, we're likely going to get rid of the
    HIGH expression as well.  Other ports cost symbolics much higher and the RISC-V
    port may want to follow suit at some point, but for now we can just add a
    single unit to the LO_SUM expression cost and all the right things happen --
    hopefully with no fallout.
    
    This has been tested on riscv32-elf and riscv64-elf.  Bootstraps on the K3 and
    c920 will run overnight, but I don't expect any issues.  Pushing to the trunk.
    
            PR target/108031
    gcc/
            * config/riscv/riscv.cc (riscv_rtx_costs): Bump the cost of a LO_SUM
            by one unit to encourage use of related values instead of the symbolic
            form.
    
    gcc/testsuite
            * gcc.target/riscv/pr108031-2.c: New test.

Diff:
---
 gcc/config/riscv/riscv.cc                   | 11 ++++++++++-
 gcc/testsuite/gcc.target/riscv/pr108031-2.c |  9 +++++++++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index f79b55a0c705..a2a51c019ec1 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -4773,8 +4773,17 @@ riscv_rtx_costs (rtx x, machine_mode mode, int outer_code, int opno ATTRIBUTE_UN
       return false;
 
     case LO_SUM:
+      /* The +1 at the end is to make this ever-so-slightly more
+	 expensive than a simple PLUS to encourage CSE-ing the
+	 symbolic expression with related symbolic expressions.
+
+	 While both PLUS and LO_SUM will turn into an add insn, if
+	 we can convert the LO_SUM to a constant offset from another
+	 expression, then we'll be able to eliminate the HIGH
+	 insn.  */
       *total = (set_src_cost (XEXP (x, 0), mode, speed)
-		+ set_src_cost (XEXP (x, 1), mode, speed));
+		+ set_src_cost (XEXP (x, 1), mode, speed)
+		+ 1);
       return true;
 
     case LT:
diff --git a/gcc/testsuite/gcc.target/riscv/pr108031-2.c b/gcc/testsuite/gcc.target/riscv/pr108031-2.c
new file mode 100644
index 000000000000..423334df8ede
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/pr108031-2.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc -mabi=lp64d " { target { rv64 } } } */
+/* { dg-options "-march=rv32gc -mabi=ilp32d " { target { rv32 } } } */
+/* { dg-skip-if "" { *-*-* } { "-O0" } } */
+
+#include "pr108031.c"
+
+/* { dg-final { scan-assembler-times "%hi" 2 } } */
+/* { dg-final { scan-assembler-times "%lo" 2 } } */