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

[Zdenek Dvorak]

Hello,

> >>>This is normal for both the RTL and tree level, apparently (IE this 
> >>>is what has always happened when we remove loops).
> >>It sounds like something that could be easily remedied tho...  if you 
> >>remove a loop, compress the remaining ones and decrement the number 
> >>of levels.   Or am I missing something about why we wouldnt want to 
> >>do that.
> >
> >I'm thinking somebody decided it's O(n^2) to do that (if we just omve 
> >the last loop into the array hole, we have to update the loop index, 
> >and i'm not sure if that is supposed to be invariant or not :P), and 
> >thus decided that doing this was better.
> >Who knows :)
> >I'm just guessing, it'd be nice to find out the real reasoning behind 
> >this design.
> 
> Are you sure there was a design?  This looks like behavior you might 
> 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).

Compressing the array between optimizations would of course be harmless,
but usually there are not that many loops removed, so it does not seem
to be worth worrying about.

Zdenek