[Bug target/111466] RISC-V: redundant sign extensions despite ABI guarantees

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #4 from CVS 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:8eb9cdd142182aaa3ee39750924bc0a0491236c3

commit r14-4676-g8eb9cdd142182aaa3ee39750924bc0a0491236c3
Author: Vineet Gupta <vineetg@rivosinc.com>
Date:   Mon Oct 16 21:59:09 2023 -0600

    expr: don't clear SUBREG_PROMOTED_VAR_P flag for a promoted subreg
[target/111466]

    RISC-V suffers from extraneous sign extensions, despite/given the ABI
    guarantee that 32-bit quantities are sign-extended into 64-bit registers,
    meaning incoming SI function args need not be explicitly sign extended
    (so do SI return values as most ALU insns implicitly sign-extend too.)

    Existing REE doesn't seem to handle this well and there are various ideas
    floating around to smarten REE about it.

    RISC-V also seems to correctly implement middle-end hook PROMOTE_MODE
    etc.

    Another approach would be to prevent EXPAND from generating the
    sign_extend in the first place which this patch tries to do.

    The hunk being removed was introduced way back in 1994 as
       5069803972 ("expand_expr, case CONVERT_EXPR .. clear the promotion
flag")

    This survived full testsuite run for RISC-V rv64gc with surprisingly no
    fallouts: test results before/after are exactly same.

    |                               | # of unexpected case / # of unique
unexpected case
    |                               |          gcc |          g++ |    
gfortran |
    | rv64imafdc_zba_zbb_zbs_zicond/|  264 /    87 |    5 /     2 |   72 /   
12 |
    |    lp64d/medlow

    Granted for something so old to have survived, there must be a valid
    reason. Unfortunately the original change didn't have additional
    commentary or a test case. That is not to say it can't/won't possibly
    break things on other arches/ABIs, hence the RFC for someone to scream
    that this is just bonkers, don't do this ð

    I've explicitly CC'ed Jakub and Roger who have last touched subreg
    promoted notes in expr.cc for insight and/or screaming ð

    Thanks to Robin for narrowing this down in an amazing debugging session
    @ GNU Cauldron.

    ```
    foo2:
            sext.w  a6,a1             <-- this goes away
            beq     a1,zero,.L4
            li      a5,0
            li      a0,0
    .L3:
            addw    a4,a2,a5
            addw    a5,a3,a5
            addw    a0,a4,a0
            bltu    a5,a6,.L3
            ret
    .L4:
            li      a0,0
            ret
    ```

    Signed-off-by: Vineet Gupta <vineetg@rivosinc.com>
    Co-developed-by: Robin Dapp <rdapp.gcc@gmail.com>

            PR target/111466
    gcc/
            * expr.cc (expand_expr_real_2): Do not clear SUBREG_PROMOTED_VAR_P.

    gcc/testsuite
            * gcc.target/riscv/pr111466.c: New test.