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 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
CHREC nodes).

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 flow_loops_level_compute

Maybe i should just delete it.


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