Serious performance regression -- some tree optimizer questions

[Ulrich Weigand]

Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> wrote on 12/29/2004
05:06:30 PM:

> > Together with --param iv-consider-all-candidates-bound=100
> > I'm now getting quite good code for the resid routine.
> >
> > The reason why I still need that param appears to be that
> > ivopts does not recognize that an IV like &A[i] is related
> > to a use like &A[i+1].  It appears that add_address_candidates
> > would be supposed to handle this, but it doesn't -- it only
> > sees though array references with a constant offset, not those
> > with an offset that itself has a variable and a constant part.
> >
> > I've tried to add code recognizing that case there, but then
> > the candidates still aren't chosen because they get assigned
> > very high cost; this is because fold-const is unable to
> > determine that &A[i+1] - &A[i] is a constant ...
>
> try including these patches:
>
> http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01381.html
>
> I think they might help with some of the problems you mention
> above.

Indeed, the patch #7 on that mail does generate the correct
candidates in add_address_candidates, and it also assigns them
low cost so they are chosen.  In fact, with your sign-extend
patch and patch #7 I'm getting exactly the optimal set of
IVs selected.

Unfortunately, when ivopts then tries to adapt the uses of the
form &A[i+1] to an IV representing &A[i], it simply emits code
of the form IV + &A[i+1] - &A[i], and expects fold to clean
this up to IV + sizeof (A[0]) -- which doesn't happen.

I've added a hack to get_computation_at to *also* call
strip_offset (just like get_computation_cost_at now does
when patch #7 is applied), and now I'm getting good code ...


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com