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 9 -- loop unrolling&peeling


Hello,

> > > > /* Check whether to peel LOOPS (depending on FLAGS) completely and do so.  */
> > > > static void
> > > > peel_loops_completely (loops, flags)
> > > >      struct loops *loops;
> > > >      int flags;
> > > > {
> > > ...
> > > >       /* Do not peel cold areas.  */
> > > >       if (!maybe_hot_bb_p (loop->header))
> > > 
> > > Why does hotness come into it?  Shouldn't this be a code
> > > size reduction in all cases?
> > > 
> > > >       if (!can_duplicate_loop_p (loop))
> > > 
> > > Likewise, why would we have to duplicate the loop at all?
> > > Can't we modify it in situ?  Indeed, it would seem that 
> > > not having to duplicate all that rtl would be a nice win.
> > 
> > your comments apply only for once-rolling loops; while both
> > of them make sense, I am not quite sure this special case is worth
> > bothering at all.
> 
> I would add the code for it.  IMO CSE won't do that trick.  Constant
> propagation may, but not in all cases.

the point is, how often such loops occur? The only real case that I am
aware of is the do {} while (0) construct used for macros, and this
is eliminated much earlier.

The fact is that the way I am achieving complete peeling (peeling the
neccessary number of copies and then removing the whole remaining loop)
is cumbersome. I will try to do it in more sane way.

Zdenek


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