https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111466
Bug ID: 111466 Summary: RISC-V: redundant sign extensions despite ABI guarantees Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: vineetg at gcc dot gnu.org Reporter: vineetg at gcc dot gnu.org CC: aagarwa at gcc dot gnu.org, jeffreyalaw at gmail dot com, jivanhakobyan9 at gmail dot com, kito at gcc dot gnu.org, palmer at gcc dot gnu.org Target Milestone: --- Consider the test below: int foo(int unused, int n, unsigned y, unsigned delta){ int s = 0; unsigned int x = 0; // if int, sext elided for (;x<n;x +=delta) s += x+y; return s; } -O2 -march=rv64gc_zba_zbb_zbs foo2: sext.w a6,a1 # 1 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 I believe the SEXT.W is not semantically needed as a1 is supposed to be sign extended already at call site as per psABI [1]. I quote "When passed in registers or on the stack, integer scalars narrower than XLEN bits are widened according to the sign of their type up to 32 bits, then sign-extended to XLEN bits" However currently RISC-V backend thinks otherwise: changing @x to int, causes the the sign extend to go away. I think both the cases should behave the same (and not generate SEXT.w) given the ABI clause above. Note that this manifests in initial RTL expand itself generating/or-not-generating the sign_extend so if it is unnecessary we can avoid late fixups in REE. Andrew Waterman confirmed that the ABI guarantees this and that the SEXT.W is redundant [1] [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630811.html