range-op-float: Further comparison fixes

range-op-float: Further comparison fixes

On Fri, Mar 31, 2023 at 09:57:54AM +0200, Jakub Jelinek via Gcc-patches wrote:
> and so if maybe_isnan, they always return [0, 1].  Now, thinking about it,
> this is unnecessary pessimization, for the case where the ... block
> returns range_false (type) we actually could do it also if maybe_isnan (op1,
> op2), because if one or both operands are NAN, the comparison will be false,
> and if neither is NAN, the comparison will be also false.  Will fix
> incrementally today.

Here it is.
1) the foperator_{,not_}equal::fold_range cases
   - we have correctly first a case handling known_isnan on either operand,
     return there range_false (type) - EQ, resp. range_true (type) - NE
   - next we handle the singleton cases, maybe_isnan + singleton isn't
     singleton, so these are ok
   - there is a missing case (not handled in this patch) where both operands
     are known to be zeros, but not singleton zeros
   - there is some !maybe_isnan (op1, op2) handling which tries to prove
     when the operands are certainly not equal and results in
     range_false (type) - EQ, resp. range_true (type) - NE
   - otherwise range_true_and_false (type)
   Now, I think (and this patch implements it) that the !maybe_isnan (op1, op2)
   check is unnecessary.  If we prove that when ignoring maybe NANs, the
   ranges don't intersect and so the comparison is always false for EQ or
   always true for NE, if NANs can appear, it doesn't change anything on
   that either, for EQ if NAN appears, the result is false like what we
   proved for the finite ranges, for NE if NAN appears, the result is true
   like what we proved for the finite ranges
2) foperator_{lt,le,gt,ge}::fold_range cases
   - these have correctly known_isnan on either operand first and return
     there range_false (type)
   - then !maybe_isnan (op1, op2) condition guarded checks
   - finally range_true_and_false (type) - so do that for
     maybe_isnan (op1, op2)
   Here in the !maybe_isnan (op1, op2) guarded code we have some condition
   which results in range_true (type), another condition which results in
   range_false (type) and otherwise range_true_and_false (type).
   Now, the condition which results in range_false (type) can be IMHO done
   also for the maybe_isnan (op1, op2) cases, because it is [0, 0]
   if both operands are finite or [0, 0] if either operand is NAN.
3) finally, LTGT_EXPR wasn't handled at all.  LTGT_EXPR is the inverse
   comparision to UNEQ_EXPR, I believe both raise exceptions only if
   either operand is sNaN, UNEQ_EXPR is true if both operands are
   either equal or either of the operands is NAN, while LTGT_EXPR is
   true if the operands compare either smaller or larger and is false if
   either of the operands is NAN.

2023-04-01  Jakub Jelinek  <jakub@redhat.com>

	* range-op-float.cc (foperator_equal::fold_range): Perform the
	non-singleton handling regardless of maybe_isnan (op1, op2).
	(foperator_not_equal::fold_range): Likewise.
	(foperator_lt::fold_range, foperator_le::fold_range,
	foperator_gt::fold_range, foperator_ge::fold_range): Perform the
	real_* comparison check which results in range_false (type)
	even if maybe_isnan (op1, op2).  Simplify.
	(foperator_ltgt): New class.
	(fop_ltgt): New variable.
	(floating_op_table::floating_op_table): Handle LTGT_EXPR using
	fop_ltgt.

	* gcc.dg/torture/inf-compare-1.c: Add dg-additional-options
	-fno-tree-dominator-opts -fno-tree-vrp.
	* gcc.dg/torture/inf-compare-1-float.c: Likewise.
	* gcc.dg/torture/inf-compare-2.c: Likewise.
	* gcc.dg/torture/inf-compare-2-float.c: Likewise.