On 10/25/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> >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.
it definitely is not the only way,
I do not know what is the best approach. One expect discipline from passes
and other require some way to know what pass did.
and seeing the reaction of people,
I probably won't use it. The main reason for considering to use
the tree node for me was the possibility to make the number of iterations
of the loop as its operand, so that I would not need to worry about
keeping it alive through dce, copy/constant propagation, etc. (without
a statement carrying it in IL, I do not see a solution that would not
be just asking for introducing bugs and getting broken accidentally).
One way to achieve this is to mark n_1 (in your example) as
"do not dead strip because I know it is used" , kind of attribute((used)).
-
Devang
