This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Fix places where we expect non-null loops in the loop array
> >>get by accident (i.e. a lurking bug).
> >no, it is expected behavior. As for why I decided to do it this way --
> >so that the numbers of the loops do not change in the middle of an
> >optimization (so you can for example store some information for loops
> >in an array indexed by loop numbers). I do not think it is seriously
> >used anywhere (except perhaps for scev, that store loop numbers in
> >CHREC nodes).
> SCEV also depends on the indexes being in a certain order (DFS order in
> this case).
> Is this behavior guaranteed?
it is in general preserved that a loop has higher number than all its
superloops (except maybe in the "linear" pass -- I do not know whether
you change the loop numbers when you swap them or not). We indeed rely
on this invariant on several places. Scev is the only one I know about
where the dependency is critical -- on other places violating it would just
mean that outer loops would be processed before inner ones, possibly
decreasing the efficiency of the optimization.