Re: [PATCH 2/2] Add VREL_OTHER for FP unsupported relations.

[Jakub Jelinek <jakub@redhat.com>]

On Wed, Jan 25, 2023 at 06:23:25PM -0500, Andrew MacLeod wrote:
> > > --- a/gcc/gimple-range-fold.cc
> > > +++ b/gcc/gimple-range-fold.cc
> > > @@ -1039,6 +1039,9 @@ fold_using_range::relation_fold_and_or (irange&
> > > lhs_range, gimple *s,
> > >     if (!ssa1_dep1 || !ssa1_dep2 || !ssa2_dep1 || !ssa2_dep2)
> > >       return;
> > > 
> > > +  if (HONOR_NANS (TREE_TYPE (ssa1_dep1)))
> > > +    return;
> > > +
> > >     // Make sure they are the same dependencies, and detect the order of the
> > >     // relationship.
> > >     bool reverse_op2 = true;
> > > 
> > > 
> > If this works, maybe (does something check if ssa1_dep1 has certain
> > type (I assume ssa1_dep2 has to have the same) then ssa2_dep{1,2} has that
> > type too (or uselessly equal to that)?  Though, if this spot has both
> > operands of the comparison, could we for HONOR_NANS case ask frange if
> > any of them is maybe_nan or known_nan and punt only if anything can be NAN?
> 
> 
> it bootstraps with no regressions.
> 
> all the ssa?dep? must have the same type, or the comparisons for similarity
> are going to fail.  ir requires the same 2 ssa-name in both relational
> expressions, which means they must all be the same type.
> 
> At this point we don't actually know ranges.. this is a higher level thing
> before any queries have happen.   we could query, but I'd punt on that for
> next release :-)  And think about how applicable it is.  Id like to revisit
> this entire situation.

LGTM for GCC 13.  For GCC 14 we should IMHO really support all 16
possible relations and deal with them correctly.

	Jakub