https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791
--- Comment #14 from amker at gcc dot gnu.org --- (In reply to Bill Schmidt from comment #13) > 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. According to comment #6, I think IVOPTs computed correct cost because multiplication "_17 = _18 * 8;" is actually a bit-shift.
