https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791
--- Comment #13 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Actually it appears that the IVOPTS change results in worse code going into
SMS, regardless of whether SMS can succeed on the loop. It comes down to the
fact that IVOPTS formerly pulled a multiply (left-shift) out of the loop, but
now the multiply remains in the loop.
After all the do_loop work and so forth, we end up with the following going
into SMS. The r247884 loop is on the left, r247885 on the right:
lab27: lab20:
r162, ca = r162 >> 1 r157, ca = r157 >> 1
r169 = r162 << 3 r163 = r157 << 3
r166 = (r160 << 3) & 0xfffffff8
r171 = r177 + r164 r167 = r172 + r166
*(r177 + r169) = r171 *(r172 + r163) = r167
r174 = (SI)r164 + 32 r169 = (SI)r160 + 4
r164 = zext(r174) r164 = sext(r169)
bdnz r178, lab27 bdnz r173, lab20
The loss of hoisting of the multiply/shift shows up in the optimized and vregs
dumps as well; RTL optimizations aren't able to recover from this.
So I think this still comes down to an unfortunate choice made in IVOPTS.
