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

[Andrew MacLeod <amacleod@redhat.com>]

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
>