This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Fix places where we expect non-null loops in the loop array


> >>easily
> >>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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]