Re: [patch] for PR 18687

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > >	This patch has a good effect if -funroll-loops also is enabled,
> > >but a very bad effect without.  For instance, on our tests, swim loses
> > >nearly 20% performance with the patch when using options
> > >
> > >-O2 -mcpu=power4
> > >
> > >versus
> > >
> > >-O2 -mcpu=power4 -funroll-lops -fpeel-loops
> > 
> > That's disturbing.
> > 
> > Unless we were just getting incredibly lucky before, I'm concerned about 
> > this issue, as using "-O2 -mcpu=power4" is the optimization setting more 
> > likely to be used by most people.
> > 
> > Zdenek, from your original posting it sounded like the two improvements 
> > that you made should not affect the generated code.  You describe (a) 
> > memoizing the result of a frequently called function, and (b) speeding 
> > up a check that gates whether or not it is possible to perform the 
> > optimization.
> > 
> > Did you expect your change to have other side-effects?
> 
> no, this should have been purely compile time improvement.  I should
> have time to check what's going on during this week.

the patch indeed makes us able to detect induction variable elimination
opportunities on wider range of loops (well, at least different; it is
very likely that there are examples detected by the old approach, but
not the new one) -- the original approach was too conservative and
depended on expressions for numbers of iterations before and after being
exactly the same, which sometimes was not the case -- differently placed
casts or in other way equivalent ways of expressing the expressions
caused the check to fail.

This exposed a problem in determining cost of such an use -- we did not
strip casts in force_var_cost, thus rating expressions like
(unsigned) i as very expensive, leading to a wrong choice of induction
variables.  Applying the straigtforward fix (below) fixes the
problems for me (with the gcc checked out at -D '2005-02-10 01:32:49').

Since the patch is already in mainline (since my commit on 2005-02-10),
I hope the problem is fixed.  David, can you confirm that, or does the
problem still reproduce for you?

Zdenek

Index: tree-ssa-loop-ivopts.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-loop-ivopts.c,v
retrieving revision 2.45
diff -c -3 -p -r2.45 tree-ssa-loop-ivopts.c
*** tree-ssa-loop-ivopts.c	10 Feb 2005 00:32:45 -0000	2.45
--- tree-ssa-loop-ivopts.c	23 Feb 2005 00:09:46 -0000
*************** force_var_cost (struct ivopts_data *data
*** 2841,2846 ****
--- 2841,2848 ----
        costs_initialized = true;
      }
  
+   STRIP_NOPS (expr);
+ 
    if (depends_on)
      {
        fd_ivopts_data = data;