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
