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: [PATCH] rtlopt branch merge part 5 -- loop unswitching


> Hello,
> 
> > > this patch brings in loop unswitching pass.
> > 
> > Looking at everything except loop-unswitch.c here, since
> > that was updated under separate cover.
> > 
> > >     { "bp",	'b', 1, 0, 0 },
> > >     { "ce1",	'C', 1, 0, 0 },
> > >     { "tracer",	'T', 1, 0, 0 },
> > > +   { "loop2",	'L', 1, 0, 0 },
> > >     { "cse2",	't', 1, 0, 0 },
> > 
> > Wouldn't we prefer to do unswitching before move_movables,
> > or even induction variable analysis?
> > 
> > I imagine that we'd very much like the loop-oriented cfg
> > cleanups that take place here as well.  But I can also guess
> > that it would kill the LOOP notes that loop.c uses, so we'd
> > have to wait for more merging for this to get fixed.  Correct?
> 
> more importantly, loop.c kills cfg; without cfg, we don't have profile
> feedback; without profile feedback, everything is much less cool :-)
> 
> Lost loop notes would probably not be that much of a problem; I have
> considered idea to just throw them away and regenerate them from
> the loop analysis we do.

Jeff was playing around with this idea and I think he do have some code
working.  There is problem with LOOP_VTOP note.

In general, I am bit nervous about using LOOP notes after major CFG
reorganization as we do in tracing, bb reordering and now in
unswitching.  What about killing the notes just after loop pass?
I know that this will affect CSE and reorg that do use them, but we used
this for some time on cfg branch and at least the negative effects on
CSE wasn't serious.

Honza
> 
> Zdenek


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