Re: [PATCH] PR tree-optimization/108447 - Do not try to logical fold floating point relations.

[Andrew MacLeod <amacleod@redhat.com>]

On 1/26/23 02:13, Richard Biener wrote:
> On Thu, Jan 26, 2023 at 8:09 AM Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Wed, Jan 25, 2023 at 7:05 PM Andrew MacLeod <amacleod@redhat.com> wrote:
>>> This boils down to a single place where we are trying to do things with
>>> relations in ranger that are simply not safe when we need to honor NANs.
>>>
>>> I think we can avoid all the other shuffling of relations, and simply
>>> not perform this optimization when it comes to floats.
>>>
>>> The case the routine handles is:
>>>
>>> c_2 = a_6 > b_7
>>> c_3 = a_6 < b_7
>>> c_4 = c_2 && c_3
>>>
>>> c_2 and c_3 can never be true at the same time, Therefore c_4 can always
>>> resolve to false based purely on the relations.
>>>
>>>
>>> Range-ops is unable to do this optimization directly as it requires
>>> examining things from outside the statement, and is not easily
>>> communicated a simple relation to operator_logical_and.
>>>
>>> This routine proceeds to look at the definitions of c_2 and c_3, tries
>>> to determine if there are common operands, and queries for any relations
>>> between them.   If it turns out there is something, depending on whether
>>> its && or || , we use intersection or union to determine if the result
>>> of the logical operation can be folded.  If HONOR_NANS is true for the
>>> float type, then we cannot do this optimization, and bail early.
>>>
>>> At this point I do not think we need to do any of the other things
>>> proposed to relations, so we don't need either of the other 2 patches
>>> this release.
>>>
>>> Bootstraps on x86_64-pc-linux-gnu with no regressions.  OK for trunk?
>> +  if (HONOR_NANS (TREE_TYPE (ssa1_dep1)))
>> +    return;
>>
>> would that rather be !(range-includes-nan (ssa1_dep1) ||
>> range-includes-nan (ssa1_dep2) || ..)?
> Saw the discussion in the other thread only now, so OK.
>
>> That said, if the other 2 patches fix some latent issues in the new
>> frange code I'd
>> rather have them fixed.
> So do we know bugs in the current code?  You said some buggy
> function isn't used, so better delete it.  Are there other latent issues?
>
No bugs :-) At leats not related tot hat.    Yes, negate turns out to 
not currently be used (im sure it will eventually), but without the 
VREL_OTHER or other changes to relation representation, the negate table 
is currently correct.

Andrew