Re: [patches] Re: reversing of FP conditions infrastructure

[Jan Hubicka <jh at suse dot cz>]

> 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.
Thanks!
> > 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.
Exactly - thats what I am trying to get on.
Problem is that the compare is under controll of the comparison mode
and that depends on the condition code (indirectly trought CC_MODE).

Take i386 as an example - we do have better instructions for trapping compares
than for non-trapping compares (fcom takes memory argument, unlike fucom and
SSE is able to do conditional moves using fcomi), but the trapping compares 
may not trap if exceptions are masked.

Now the generic code sees set flags instructions:
(set (reg) (le (fp1) (fp2))
This is approximately behaviour of SSE comss (or whatever is the name)
that sets takes two fp arugments and sets result to 0 or NAN depending
on the condition code.

The code wants to reverse the condition - it can't use UNLT, since it
converts possibly-trapping test to never trapping, that may not be supported.
In case it use NTUNGT, it does the right thing.

Reversing again will bring us back to LT.

If we didn't had the NT* familly, we will convert LE to UNGT, that is also
correct, but converting again will bring us to ORDLE and we will get non-masking
behaviour.
This is quite strange - I think that sane comparison codes should behave
in a way to makre two reverses bring the to same code. This is even
required by some parts of compiler - such as condition_mutex in the haifa.
> 
> > 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,
Imagine i386 w/o fu* familly of isntructions, thats what we have.

I really believe that most machines do have it, since most branches
are reversible.
> 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.
Then the pattern will just refuse the cases it can't handle directly.
Generic code should always behave in a way to verify that instruciton
is valid after the transformation - this is currently required anyway
due to possible changes in CCmode. This will inhibit generic code from
reversing the conditions, but since the conditions are not reversible,
thsi is right think.

If machine description will be asked to generate conditional branch
or move using such unsupported code, it can just manage to reverse
the branch to get existing mode (we can probably manage the
emit infrastructure to do the reversal into the "nice" forms
before calling machine description to avoid problems with existing
ports).

Honza