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:
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
Okay, so, uh, guys, what do you want me to do?
Make things ignore null loops (which is what everything does now)?
it seems to be the simplest choice to me.
Invalidating the loop indexes by compression will screw over scev's cache,
which will cause a performance regression at the expense of a few if's in
the other code.
I can of course, go through and figure out the new num_levels and depth,
etc, without compressing the array.
loop->depth is always updated, so you do not have to go through everything to
get it. I do not know what num_levels is supposed to be (which very
likely means that it is not updated, and you would really have to go
over the loops and determine it).
It's not num_levels, sorry, it's loops->levels.
it looks like max depth (it claims its the height of the loop tree)>
It's actually unused except to dump it out, and as the value returned by
Maybe i should just delete it.