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 >
