https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124956
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So with 125731 fixed I was looking at this again today. Since I last looked at
this I'd been pondering the possibility that the sequence may not be correct.
To recap we currently generate:
slliw a5,a1,6 # 28 [c=8 l=4] ashlsi3_extend
czero.eqz t0,a5,a0 # 30 [c=4 l=4] *czero.eqz.didi
czero.nez a0,a1,a0 # 31 [c=4 l=4] *czero.nez.didi
add a0,a0,t0 # 18 [c=4 l=4] *adddi3/0
So we have the original value in a1 and the shifted value in a5 and we select
across those. The question is can we safely select the shift value of 0/6
instead and generate something like this:
li a5,6
czero.eqz a0,a5,a0
sllw a0,a1,a0
Consider when the condition is false. In the first sequence that will select
a1. In the second sequence it selects a1 reinterpreted as a 32 bit value, then
sign extended to a 64 bit value. Ie the upper 32 bits may differ across those
two sequences. Not good.
This issue probably spoils most opportunties we may have to optimize SI cases
on rv64. Closing this as INVALID.
