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 looparray
On Wed, 8 Dec 2004, Zdenek Dvorak wrote:
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
SCEV also depends on the indexes being in a certain order (DFS order in
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 can do more than just swap loops.
We can more or less arbitrarily change the loop nesting order.
To prevent problems caused by trying to figure out where a given loop
went, and because the transformations involve more than just loop
swapping, we never actually mess with the cfg.
We just rewrite the loop conditions, induction variables, and bodies so
that they act as if they were swapped.
If we only did interchange, we of course would have just redirected some
edges and changed the loop indexes.