Re: Your proposed change to loop.c

[Joern Rennecke <amylaar at cygnus dot co dot uk>]

> As long as you're sure this gets initialized, I'm OK with it.  But, a
> comment about when the field is set might be reasonable, yes?

OK.

> 
>     >> Now, the hard questions:
>     >> 
>     >> o I don't understand what the bug is in find_life_end that is
>     >> causing the current endless loop.  Please explain it to me,
>     >> bearing in mind that I am not an long-time expert loop.c hacker
>     >> like yourself!  (Of course, I do know about compilers in
>     >> general, and GCC in particular, and understand loop
>     >> optimizations.)  I don't find the loop.c comments terribly
>     >> helpful (not the ones in your patch, the ones already in the
>     >> code.)
>     >> 
>     >> I'd also like to know on which system your original change was
>     >> bootstrapped, and why the bug didn't appear there.  That would
>     >> probably help me understand what's going on a little better.
> 
>     Joern> It was bootstrapped on i686-pc-linux-gnulibc1 .  Note that
>     Joern> patches are seldom approved in the same order nor the same
>     Joern> context as they were submitted and tested before submittal.
> 
> Unfortunately, this answer didn't really answer my questions.  In
> particular, I still don't understand the bug.  Why are we getting
> stuck in an endless loop?  What about your previous changes caused
> this problem?  If you just unconvered a latent bug, what is the bug,
> and how did it get uncovered?

The loop that initialized stats[i].start_luid, stats[i].end_luid and
increments end_needs_computing uses the numbering from before the
first sort.  By having v->ix point back with the same numbering
scheme, find_life_end could properly function, but the results
were just garbled.
I suppose you can fix that by setting i to v->ix instead of incrementing it.

>  In any case, wouldn't you agree that you have a responsibility to
> test each check-in?  In other words, before you check in a patch,
> apply just that patch to an otherwise virgin tree and test?  I can't
> tell from your comments whether you did this, or whether you tested a
> much larger patch sometime back, and just recently applied a little
> piece of it.

I don't see much point in checking a toolchain with known bugs, when
there are already fixes available.  You'll just end up finding the same
bugs over and over again, and unable to do anything.

> I'd love to have all the great optimizations you're working on.  But,
> first I need to understand the current patch.  What does it do?  Why?

It looks for the actual time a giv is used, discounting any uses
that will go away because of other givs that are to be reduced.
The code that loop churns out is geared to be worked on later by
regmove.  When we have a series of derived givs with non-overlapping
lifetimes in the same basic block (as in first to last use, the time they
are set within the block is irrelevant), they will usually end up
in a single register.

> I agree that a redesign is probably in order.  But, we have to get
> there in an orderly fashion.  If it's really a large effort/rewrite,
> then it might make sense to do what RTH has done with IA32.  You could
> work on it for a while.  Then we could put it in the tree,
> conditionally compiling either your loop optimization rewrite or the
> original.  Then, folks could test it until it was stable; then we
> could make the new stuff the default.  Might or might not be a good
> plan, depending on the circumstances.

Oh, I've worked on it for quite a while.  So are you proposing to put
an alternate loop.c in the tree?  Or putting two sets of code in the
same file?