https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #17 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #15)
> I went through the whole rr_{intersect,union}_table tables and I think just
> --- gcc/value-relation.cc.jj 2023-01-02 09:32:42.088000605 +0100
> +++ gcc/value-relation.cc 2023-01-19 16:20:06.490126901 +0100
> @@ -115,7 +115,7 @@ relation_kind rr_union_table[VREL_LAST][
> { VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING,
> VREL_VARYING, VREL_VARYING, VREL_VARYING },
> // VREL_UNDEFINED
> - { VREL_VARYING, VREL_LT, VREL_LE, VREL_GT, VREL_GE, VREL_UNDEFINED,
> + { VREL_VARYING, VREL_UNDEFINED, VREL_LT, VREL_LE, VREL_GT, VREL_GE,
> VREL_EQ, VREL_NE },
> // VREL_LT
> { VREL_VARYING, VREL_LT, VREL_LT, VREL_LE, VREL_NE, VREL_VARYING, VREL_LE,
> is really wrong for the integral/pointer relations (plus the question what
> to do with the VREL_PE* relations and whether they need to be in the tables
> or punted on by the caller somehow).
THat was my conclusions as well.
As for the PE's.. it seemed easier just to leave the partial equivalences
there as the table only grows from 64 to 144 entries, and in the grand scheme
seemed easier than trying to add runtime checks for relation kind ranges just
to avoid those few extra words.
Besides, if we ever end up with x != y when there is a partial equivalence, we
may also be able to conclude x > y or something else.. just left the window
open for exploration.
>
> Now, when considering the relations in the fp with NAN meaning they have in
> C/C++
> (and assuming we don't try to replace say two actual comparisons in the IL
> with one
> with different exception behavior), the only relations in the tables which
> are true for unordered operand(s) are VREL_VARYING and VREL_NE. Maybe I
> miss something, but I can't think of an inappropriate intersection -
> VREL_VARYING intersects anything is anything,
> VREL_VARYING intersect VREL_VARYING is the only one that gives VREL_VARYING,
> VREL_{VARYING,NE} intersect VREL_NE or vice versa the only one that gives
> VREL_NE
> and VREL_UNDEFINED returned only from intersections of anything and
> VREL_UNDEFINED, or
> LT/LE/GT/GE vs. each other where there is no overlap (but in that case
> neither allows NANs), LT/GT vs. EQ (ditto) and EQ vs. NE (one relation
> doesn't allow NAN but the other does, so they aren't allowed.
> As for unions - LT U GT or vice versa is incorrectly NE, should be LAST or
> LTGT or some other way how to express we can't express it. LT U GE or LE U
> GT or LE U GE or vice versa are incorrectly VARYING, when they are together
> ORDERED (so again, need some way how to express that). Can't find anything
> else wrong.
> But unless we use VR_UNKNOWN or VR_LAST or whatever to stand for something
> we really don't know how to handle, we'd need the various combinations that
> tree.def has on top of the basics, LTGT, UNORDERED, ORDERED, UNLT, UNLE,
> UNGT, UNGE and UNEQ.
For this release, I wouldn't want to add too much extra stuff. Im inclined to
handle this pretty much where the problems arise as I think it is fairly
localized.
For the next release, I'm inclined to enhance the oracle and relations such
that any range class can specify its own relation sets.. so irange (and most
others) would use a set which implements what we have, and we could introduce a
floating point relation set which includes something like "<>" and "<=>" and we
can work out what that looks like to cover exactly what we need to model.
That way we can model slight behaviour changes more easily.
