[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

[amker at gcc dot gnu.org]

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.