[Bug target/124019] Improve subword arithmetic and comparisons

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jeff Law <law@gcc.gnu.org>:

https://gcc.gnu.org/g:9496224132aa7179219195f218e3a4c7eb13b9ce

commit r17-1854-g9496224132aa7179219195f218e3a4c7eb13b9ce
Author: Jeff Law <jeffrey.law@oss.qualcomm.com>
Date:   Thu Jun 25 07:24:49 2026 -0600

    [RISC-V][PR target/124019] Add pattern to improve QI comparisons on RISC-V

    So after much head-banging from Daniel and myself I think it's time to
    acknowledge this issue isn't great for solving in match.pd.

    Depending on the target's properties it may be advantageous to handle
    generating code for this kind of idiom in different ways:

    It may be better to mask off the irrelevant bits first, then compare to an
    adjusted constant.  It may also be better to do a simpler direct approach
of
    shifting, the comparing to the constant.  Worse yet, the desired approach
may
    vary for a given architecture depending on the type of the object (it's
related
    to what bits need to be masked off and the constant we have to generate).

    While I was able to convince myself we could canonicalize in match.pd, then
    recover the regressed cases with target work, it'd be a lot of target
testing &
    hacking.  The effort is likely equivalent to leaving match.pd alone and
    adjusting the target patterns to generate good code for the poorly handled
    cases.  ie, in both scenarios we're likely doing significant target work.

    Some quick evaluation against 502.gcc showed this never shows up in that
    benchmark. However, it does show up in a trunk bootstrap on RISC-V (given
an
    earlier version with a code generation bug triggered a bootstrap failure).
    While it's far from wide coverage, I suspect if we were to do wider testing
it
    rarely hits.

    So I'm taking the conservative approach here.  Leave match.pd alone, add a
    pattern to the RISC-V port to capture this oddball case, then move on.

    Regression tested on riscv32-elf and riscv64-elf and bootstrap and
regression
    tested on the c920 and K3 designs.  Waiting on pre-commit CI before moving
    forward.

            PR target/124019
    gcc/

            * config/riscv/riscv.md (seq_sne_qi): New define_insn_and_split.

    gcc/testsuite

            * gcc.target/riscv/pr124019.c: New test.

    Co-authored-by:  Daniel Barboza <daniel.barboza@oss.qualcomm.com>