[Bug target/29256] [4.9/5/6 regression] loop performance regression

["wschmidt at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256

--- Comment #61 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
(In reply to amker from comment #60)
> (In reply to Bill Schmidt from comment #59)
> > We don't have a lot of data yet, but we have seen several examples in SPEC
> > and other benchmarks where turning on -funroll-loops is helpful, but should
> > be much more helpful -- in many cases performance improves with a much
> > higher unroll factor.  However, the effectiveness of unrolling is very much
> > tied up with these issues in IVOPTS, where we currently end up with too many
> > separate base registers for IVs.  As we increase the unroll factor, we
> By this, do you mean too many candidates are chosen?  Or the issue just like
> this PR describes?  Thanks.
> 

On the surface, it's the issue from this PR where we have lots of separate
induction variables with their own index registers each requiring an add during
each iteration.  The presence of this issue masks whether we have too many
candidates, but in the sense that we often see register spill associated with
this kind of code, we do have too many.  I.e., the register pressure model may
not be in tune with the kind of addressing mode that's being selected, but
that's just a theory.  Or perhaps pressure is just being generically
under-predicted for POWER.

Up till now we haven't done a lot of detailed analysis.  Hopefully we can free
somebody up to start looking at some of our unrolling issues soon.