Re: Loop problem

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

> 
>   In message <199901300146.BAA10166@phal.cygnus.co.uk>you write:
>   > Here is a patch:
>   > 
>   > Sat Jan 30 01:43:52 1999  J"orn Rennecke <amylaar@cygnus.co.uk>
>   > 
>   > 	* loop.c (recombine_givs): Fix test for lifetime overlaps / loop
>   > 	wrap around when deriving givs.
> Hmmm.  It does fix the problem.  However, I would have expected the case
> where the differences are equal to indicate that the the life of one giv
> ended precisely when the other giv started.  Which I would have expected
> to be safe for combination.  Can you give a little bit more information
> on this fix?

Between end of last_giv and start of v, we want to sneak in an add.
So we actually need a place in-between.

The end test - that's where the problem was in this case - checks that there
is no wrap around.  If both ends are the same, this is - knowing that the
starts are different and in order - certainly a wrap around.

> At a higher level I also wonder if this code is safe given a loop with a
> bunch of spaghetti code.  ie, how do we know that the insns are in flow
> order?  luids don't give you that kind of information.  Can you say a little
> bit more about how this stuff works in the presense of spaghetti code?

last_giv is an ordinarily reduced giv, i.e. it is valid throughout the loop.
v has either not been combined with anything else - in that case we can
tap into last_give whereever v->insn was, and we'll be all set.

Or v->always_executed is set.  This implies that there is no jump inside the
loop before v->insn.  Thus, if v->insn comes statically before all uses
of v->dest_reg in the loop, it also comes first dynamically.

It is true that this uses more information from always_executed than that
name advertizes, but before this use is a comment what we'd *really* like
to test, so I think we should be fine also when someone starts adding
exact control flow analysis.