Re: loop.c:get_condition broken

[Jim Wilson <wilson at cygnus dot com>]

	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.

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

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

If get_condition is failing for you, then it is possible that combine is
failing also, since the intent here was to make it act more like combine.
If the get_condition change needs to be reverted, then we may have to rethink
how we deal with IEEE FP issues on the alpha, which is what this patch was
intended to fix.

The intent of the patch is that if you have one comparison in CCmode, and
one in some other mode (like DFmode), then loop should not assume that they
can be simplified.  This allows us to indicate, for instance, that some
compares produce IEEE FP correct results and some do not.  The alpha port
is using this to say that the condition move instructions are not IEEE FP
correct.

Jim