loop.c:get_condition broken

[David Edelsohn]

>>>>> Jim Wilson writes:

> This change seems to have broken loop.c:get_condition() in that it no longer
> finds a valid condition.  With this change reverted, get_condition()
> finds a condition and loop_iterations() works properly.

Jim> Please give me a more complete bug report, or point me to one.  Simply saying
Jim> that you think something is wrong with it doesn't help me track the problem
Jim> down.

Jim> I'd suspect the problem might be an interaction problem between the rs6000
Jim> port and how loop/combine handle mixed mode comparison operations, but I'd
Jim> apprepreciate having an actual testcase to look at.

	I did give you more information: loop_iterations() is not finding
a comparison and not calculating an iteration count.  With the patch
installed, get_condition() returns 0 on normal, simple loops when called
from get_condition_for_loop() called from loop_iterations().  If you look
at the output from the loop pass compiling simple loops:

"Loop unrolling: No final conditional branch found."

is printed where it was not before.  With the change reverted, a valid
comparison RTX is returned and an iteration count calculated.  Michael
Hayes seems to be experiencing the same problem, so this is not limited to
rs6000 port alone.

Loop example

	for (i=0; i<256; i++)

produces failing SET:

(set (reg/s:CC 85)
    (compare:CC (reg/v:SI 84)
        (const_int 255)))


In get_condition(), looking to find the SET:

	code = LE
	mode = VOIDmode
	inner_mode = CCmode

With the old code, it finds a valid SET_SRC; with the new code, it does
not and fails.

David