Re: reversing of FP conditions infrastructure

[Richard Henderson <rth at redhat dot com>]

On Sun, Jan 07, 2001 at 01:27:22PM +0100, Jan Hubicka wrote:
> I see now.  OK would you agree on installing this patch
> w/o this bit first?

Yes.

> To my understanding, the situation is as follows:
> 1) we have comparisons that may or may not trap (ones comming from C operators)
> 2) we have comparisons that may never trap (ones from isgreater style builtins
>    and =/!= operators)
> 3) machine may have compare instructions that
>    a) never trap (fucom)
>    b) maybe trap (fcom)
>    c) always trap (on sane non-i386 architecture)

Well, not quite -- b and c are really the same, just depending
on the default state of the fp exception mask.  I don't believe
there are any systems that truely have a "C", that is, ignore
the fp exception mask.

> I think it makes sense even for the UN* - like NTUNLT.

Think about this some more -- a trapping UNLT is useless.  You need to
return true if NaN, but the NaN caused a trap.  Oh, but I see what you
are trying to get at.  Supposing the exception is masked and execution
continues, then a trapping compare and an UNLT branch does do the right
thing.

> This would also allow us to safely optimize (reverse conditions)
> even in cases machine don't have the nontrapping instructions.

Nope.  One, if the machine doesn't have non-trapping compares, it
isn't going to have an "UNORDERED || LT" condition either.  Two,
at least Alpha and IA-64 only have an "UNORDERED" test, not an
"UNORDERED || LT".  So on those machines, with exceptions masked
(so that the trap is ignored) we either get the wrong result from
reversing the condition, or have to generate many more instructions.



r~