Re: convert jump.c, ifcvt.c, cse.c and simplify-rtx.c to new fp conditionals

[Richard Earnshaw <rearnsha at arm dot com>]

> On Sun, Jan 07, 2001 at 10:14:45AM -0800, Richard Henderson wrote:
> > No, we can't change this.  Your reversed_comparison_code will 
> > scan previous code to find the "real" comparison.  Here we need
> > exactly the inverse of the actual branch.  Which, for targets
> > that support COND_EXEC, is almost certainly going to be integral.
> 
> Actually, I'm wrong.  I was confusing reversable_comparison_p
> with get_condition.  The former only backward scans to get the
> type, the later backward scans for the whole condition.
> 
> Hmm, it's a quandry.  I'd like to know how this change affects ARM.
> That is a machine that has COND_EXEC, but more than BImode EQ/NE
> like IA-64.  ARM, iirc, implements fp branches by doing the compare
> in the fpu, then moving the condition codes into place (much like
> x86 sahf).
> 
> It's entirely possible that we've currently got things incorrect
> for ARM and you've uncovered a latent bug.  In which case we'd
> need these tests to check for UNKNOWN.

I've not been following this in detail, so I may have missed something.

The ARM can implement all FP conditions (including unordered) in a single 
instruction except for LTGT and UNEQ.  IIRC these two form a reversed 
pair, so we can safely use reverse_condition on any other comparison.  The 
unhandled comparisons are handled with special branch instructions in the 
md file which use two conditional branch instructions.  The unhandled 
cases are never allowed to be used in conditional execution.

R.