[Bug middle-end/108031] riscv: Access of members of a global structure is not optimized in atomic operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108031

--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jeff Law <[email protected]>:

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.