Re: LOOP_HEADER tree code?

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

Hello,

> > > for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
> > > introducing a tree LOOP_HEADER with single argument N (number of
> > > iterations of the loop), that would be present in IL at the beginning of
> > > header of each loop.  I have following motivations:
> > >
> > >1) One of the goals of the project is to avoid recomputing number of
> > >   iterations of loops, and to keep this information (analysing # of
> > >   iterations is fairly expensive, and we recompute this information
> > >   quite a lot at the moment).  To keep the information valid, we need
> > >   to prevent optimizations from destroying it (e.g., if the number
> > >   is n_1 = n_2 - 1, and this is the last use of n_1, we do not want
> > >   DCE to remove it); this is easy to achieve if n_1 would be the
> > >   argument of LOOP_HEADER.  Without this tree node in IL, we would need
> > >   to handle this specially in DCE, and possibly also other optimizers.
> > >2) This statement might make it simpler to ensure that various
> > >   optimizers update the loops correctly.
> > 
> > However, various optimizer needs to know about this special tree node.
> > Or am I missing something?
> Correct.  Take for example jump threading -- it can peel off a loop
> iteration which would invalidate the LOOP_HEADER node.

of course, if it does that, it must update the information at the loop
(regardless of whether we use the LOOP_HEADER node for it, or not).

> That seems
> like a recipe for disaster.

No, that seems like a good way how to detect that jump threading is
doing something it should not, or forgetting to update something in the
progress.

> Code motion passes would have to be aware of this special node as well.
> And we've seen how well that works in the RTL backend with its loop
> notes -- it was a major PITA.

The problem was that loop notes was something special, different from
other RTL statements.  Of course, we can live without LOOP_HEADER tree
node; however, that means that more optimizers will have to be aware of
information stored in loop structures, which looks more like the case
with the loop notes to me.

Zdenek

> I'd rather not repeat the mistakes we've already made.
> 
> Jeff
>