Re: reversing of FP conditions infrastructure

[Jan Hubicka <jh at suse dot cz>]

> On Sat, Jan 06, 2001 at 10:49:12PM +0100, Jan Hubicka wrote:
> > ! 	/* In case we already see unordered comparison, we can be sure to
> > ! 	   be dealing with floating point so we don't need any more tests.  */
> > ! 	return reverse_condition_maybe_unordered (code);
> 
> You can't do this genericly.  The target must support
> non-trapping forms of LT, GT, etc in order to be considered
> reverses of UNGE, UNLE, etc.

I see now. OK would you agree on installing this patch (and the transofrmations
later) w/o this bit first?
These are important stepping stones for future.



My future plan:
===============


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)

I believed that current situation is:
1) machine description supports never trapping instructions and uses them always
   and supports the UN* codes  (currently i386)
2) machine descriptions supports only possibly trapping instructions and
   does not support UN* codes

My code was correct in both cases - it works well for 1) and for 2)  as well, since
the converison in wrong direction (UN* to non UN*) never happends, since such codes
are not in insn stream.

I now see that sparc and alpha does have code that makes UN* not trap and normal
to possibly trap that is wrong with my patch.

I think we should introduce new set of codes to distinguish whether the condition
is allowed to trap or not.  So for example NTLT is LT with condition that never
trap, while LT is condition that trap.

I think it makes sense even for the UN* - like NTUNLT. With your suggestion of
introducing ORLT for non-trapping LT, but not introducing the
trapping/nontrapping UNLT have problem that after one round of reversal the
comparison will be always nontrapping.  We should keep possibly trapping
comparisons possibly trapping if possible.  This would also allow us to safely
optimize (reverse conditions) even in cases machine don't have the nontrapping
instructions.

This allows us to produce normal codes from the C operators and NT family from the
builtins and never mess them up - so reversal will work.

I think this can be hidden in simple abstraction - function returning comparison
class - the basic code such as LT/GT etc..., function returning whether comparison
accepts unordered and function returning whether comparison may trap and then
function that construct back the code from such flags.

This may be used to simplify most of the code to handle comparison - it will take
care for trapping and unordered cases first and then just do decision based on
the class.

In future we may add support for always-traping compares. This will allows us
to optimize better, but I would rather do it later, since this is tricky - for
example if you happen to optimize the compare out proving that (LT or GE) is
always trye, you will remove the compare, lose the exception and produce
incorrect code.  So it would need special care and I doubdt benefits worth it.

Sounds sane?
Honza
> 
> 
> r~