On 1/25/23 17:35, Jakub Jelinek wrote:
On Wed, Jan 25, 2023 at 11:12:11AM -0500, Andrew MacLeod via Gcc-patches wrote:
In GCC13, I don't think there are any uses of the relation oracle outside of
ranger and range-ops.
So, given that, perhaps the simplest thing to do is bail on all this change,
and instead simply do the following which also fixes the PR. (im running it
thru tests as we speak)
diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc
index 91eb6298254..9c5359a3fc6 100644
--- 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.
Andrew
Jakub
