This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Re: LOOP_HEADER tree code?
On 10/25/06, Devang Patel <devang.patel@gmail.com> wrote:
> > However, various optimizer needs to know about this special tree node.
>
> not really (not any more than they know about other tree codes that are
> not interesting for them).
If we take an example of Jump Threading pass then it needs to know
about this tree node and update it properly.
Yes, when it modifies the CFG in ways that affect the loops info. And
one nice thing about this LOOP_HEADER idea is that, in your example,
Jump Threading:
- can see that node so it knows there is something to update
- knows what it is changing so it also knows how that affects the loops info
- can change it on-the-fly
This means, no need for a cleanup pass after all changes are done.
So, the passes that maniuplate loop structure need to know about
LOOP_HEADER and others do not need to worry about LOOP_HEADER.
More acurately, the passes that manipulate the cfg. Right now most of
these passes don't even know they modify the loop structure.
Now, focusing on the passes that manipulate loop structure. Are these
pass responsible for fixing loop info or is it responsiblity of cleanup pass ?
It seems to me that a cleanup pass would defeat the purpose of keeping
loop info up to date. Your cleanup pass would probably end up just
recomputing everything.
That said, I don't really see what a LOOP_HEADER node would give you
that you can't get by making the cfg-modifying passes actually
loop-aware, or perhaps by using cfghooks to update the loop
information on the fly when a pass changes the CFG. It would be
helpful if Zdenek could give an example where a LOOP_HEADER node is
really the only way to help keep loop info accurate.
Gr.
Steven