https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #16 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So if you do the things in c#15, you will solve this BZ. Unfortunately it
seems to regress in meaningful ways on various RISC-V tests.
What seems particularly troublesome is that for this test we really want to
transform the SIGN_EXTEND notes into SUBREG notes. That givs us the ability to
ignore the upper 32 bits of those values. In other tests we really need to
avoid making that kind of transformation as it hinders combine's ability to
track sign bit copies and ultimately avoid some SIGN_EXTENDs. Consider this
(from shift-and-2.c, but there's other examples):
(insn 7 4 9 2 (set (reg:DI 140)
(sign_extend:DI (ashift:SI (subreg/s/u:SI (reg/v:DI 136 [ i ]) 0)
(const_int 10 [0xa])))) "j.c":47:13 329 {ashlsi3_dontcare}
(expr_list:REG_DEAD (reg/v:DI 136 [ i ])
(nil)))
(insn 9 7 10 2 (set (reg:DI 141)
(and:DI (reg/v:DI 137 [ j ])
(reg:DI 140))) "j.c":47:20 112 {*anddi3}
(expr_list:REG_DEAD (reg:DI 140)
(expr_list:REG_DEAD (reg/v:DI 137 [ j ])
(nil))))
(insn 10 9 15 2 (set (reg:DI 142)
(sign_extend:DI (subreg:SI (reg:DI 141) 0))) "j.c":47:20 discrim 1 133
{*extendsidi2_internal}
(expr_list:REG_DEAD (reg:DI 141)
(nil)))
In this form combine can track the number of sign bit copies for (reg:DI 140)
and since we happen to also know that data for (reg:DI 137) we can compute it
for (reg:DI 141). That ultimately leads combine to conclude that the
extension in insn 10 is redundant.
If we let ext-dce convert insn 7 to use a SUBREG, then we lose data about the
sign bit copies of (reg:DI 140) and are ultimately unable to eliminate insn 10.
