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.

Honza
> 
> > > /* Unroll LOOP with constant number of iterations LOOP->LPT_DECISION.TIMES + 1
> > >    times.  The transformation does this: 
> > >    
> > >    for (i = 0; i < 102; i++)
> > >      body;
> > >    
> > >    ==>
> > >    
> > >    i = 0;
> > >    body; i++;
> > >    body; i++;
> > >    while (i < 102)
> > >      {
> > >        body; i++;
> > >        body; i++;
> > >        body; i++;
> > >        body; i++;
> > >      }
> > 
> > I would hope this would actually transform to a do-while?
> 
> Yes.
> 
> Zdenek


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