[patches] Re: reversing of FP conditions infrastructure

[Jan Hubicka]

> Yes, it should.  But jump.c is infamous for not doing this.
I am just checking jump.c and it calls can_reverse_comparison_p on
just few places - one place deals with traps, calls expand and then checks
for validity, another place is jump_back_p function, that never
uses reversed code for something usefull and even his users don't seems
to do, third use is invert_exp, that obviously validates,
fourth is thread_jumps, that never uses reversed code.

So my guess is that we are on the safe ground - I've also run trought
testsuite with my changes and i386 modified to refuse all unordered compares.
> 
> Clean this up, and we can canonicalize jumps to have the label only in
> the "then" slot of the if_then_else.  Which allows us to clean up quite
> a lot of the rest of the compiler.  Many of the existing reversals go
> away, in fact.
Thats good point.  Another point we having full set of condition codes (being
able to reverse even on target that can't reverse) is just for internal
purposes - there are many cases where we just reverse condition to determine
dominancy relationship or inside combine or fold_const code.

I was thinking tonight about folding the FP comparisons.  I know that
currently math.h don't do it, but I still don't see purpose why
isnan(x) macro should not just test x==x, since == is guaranteed to be
nontrapping and should fail only on NANs (if I am not mistaken).

Then isordered(x,y) macro can use !isnan(x) && !isnan(y), that can be also
folded to the ORDERED code by compiler and we can eliminate need for the
builtins (and recognize such tests in pre-ISO sources that are likely
using similar tricks).

All this can be considerably more dificult without full set of CC codes.
> 
> I guess I need to think about this some more.
Mee too - thinks are getting crazy.

Honza
> 
> 
> 
> r~