This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cfg merge part 23 - simple loop analysis code


> On Tue, Jun 04, 2002 at 08:27:20PM +0200, Jan Hubicka wrote:
> > +   /* Find insn that modifies var.  */
> > +   mod_insn = NULL;
> > +   for (i = 0; i < loop->num_nodes; i++)
> > +     if (modified_between_p
> > + 	(desc->var, body[i]->head, NEXT_INSN (body[i]->end)))
> > +       {
> > + 	for (insn = NEXT_INSN (body[i]->head);
> > + 	     insn != NEXT_INSN (body[i]->end); insn = NEXT_INSN (insn))
> > + 	  if (modified_between_p
> > + 	      (desc->var, PREV_INSN (insn), NEXT_INSN (insn)))
> 
> You're needlessly searching the insn stream twice.

This is already replaced by faster analysis.

> So this is going to penalize any target that can't put 
> STRIDE directly in a PLUS insn?

I am commiting the attache dpatch for this.
> 
> Seems like you should perform a simple invariance test
> on VAL before searching.

Also killed by Zdenek.
> 
> At which point do we start making use of this information
> for more than profiling?

The code is used by unrolling/peeling to do runtime preconditioning and
full peeling epsecially.
I am not quite sure whether we can do it for 3.2.  What is missing is
about 800 lines of code to duplicate loops, remove edges and update
dominance and 600 lines of the unroller itself.

In the past Andreas did benchmarks on the branch that showed new
unroller to outperform old unroller, but it is not superset of old
unroller yet.  Our simple loop analysis is much stronger than old ones
according to the profile data, but we don't do induction variable
splitting, but one done by old unroller is redundant with webizer,
special purposed pass can do more.  Also we can't handle the VTOP notes
used by loop header duplication pass, so we end up with one extra
peeling or CSEable out test from time to time just to ensure that the
loop is not "paradoxical" - like for (i=10;i<5;i++).  This does not seem
to be big problem in practice compared to hords of problems with LOOP
notes.  It would be better to have full replacement for loop of course,
but this is long way to go.  I believe unrolling is about 30%.

Honza
> 
> 
> r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]