https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111466
Vineet Gupta <vineetg at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2023-09-28
Ever confirmed|0 |1
--- Comment #3 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
(In reply to Vineet Gupta from comment #1)
> #2. At Expand time there's an explicit sign_extend for the incoming function
> arg which is not needed per RISC-V ABI. Not generating these to begin with
> will require less fixup needs in REE and/or CSE.
>
> (insn 3 2 4 2 (set (reg/v:DI 141 [ n ])
> (reg:DI 11 a1 [ n ]))
>
> (insn 12 6 13 2 (set (reg:DI 138 [ n.1_15 ])
> (sign_extend:DI (subreg/u:SI (reg/v:DI 141 [ n ]) 0)))
Robin and I debugged this at GNU Cauldron and he narrowed it down to subreg
promoted flag being cleared out which in turn causes the sign extend to be
generated. As a hack if the flag is restored the sign extend goes away. The
only issue is that flag clearing was introduced 30 years ago, albeit w/o any
additional commentary and/or test.
commit 506980397227045212375e2dd2a1ae68a1afd481
Author: Richard Kenner <ken...@gcc.gnu.org>
Date: Fri Jul 8 18:22:46 1994 -0400
(expand_expr, case CONVERT_EXPR): If changing signedness and we have a
promoted SUBREG, clear the promotion flag.
From-SVN: r7686
Interestingly reverting this change survive the rv64gc testsuite w/o any
additional failures, so this seems to work at least for RISC-V, but may not on
other arches/ABIs.
I've posted an RFC for people familiar with the code to chime on this approach
[1]
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631641.html
