On Wed, Jan 25, 2023 at 09:30:44AM -0500, Andrew MacLeod wrote:
> > But I'm afraid the above has VREL_OTHER for too many important cases,
> > unlike intersect where it is for none unless VREL_OTHER is involved, or just
> > a few ones for union.
>
> Im not sure it is quite that bad. Floating point ranges and range-ops does
> a pretty good job of tracking NANs in the ranges. They then utilize any
> available relation in addition to that. So within floating point processing,
What I meant is that when we need to (and we have to, trying to do some
weird changes in intersect doesn't really improve anything) change the
relation_negate or its callers of a relation for floating point with
possible NANs from current inversion of VREL_{LT,GT,LE,GE} which are quite
frequent to VREL_OTHER (I don't know), it can affect a lot of code.
Now, sure, we could try to improve the situation a little bit by not
using just HONOR_NANS (type) as the decider whether we need the new 16
cases VREL_* handling (or 8 + VREL_OTHER) or whether we can use just the 8
cases VREL_* handling. Because, if HONOR_NANS (type) and frange can prove
that neither operand is maybe_nan and neither operand is known_nan, then
we can also use just the old 8 VREL_* codes and their relationships.
And perhaps if either operand is known_nan, then on the other side we know
it is VREL_OTHER (VREL_UNORDERED), not anything else.
Though, exactly for this I'd say it is more work and something for GCC 14.
Proper handling of relation_negate is I'm afraid required for GCC 13.
Jakub
