On Wed, Aug 23, 2023 at 05:22:00PM +0200, Aldy Hernandez via Gcc-patches wrote:
> BTW, we batted some ideas on how to get this work, and it seems this
> is the cleaner route with the special cases nestled in the operators
> themselves. Another idea is to add unordered relations, but that
> would require bloating the various tables adding spots for VREL_UNEQ,
> VREL_UNLT, etc, plus adding relations for VREL_UNORDERED so the
> intersects work correctly. I'm not wed to either one, and we can
> certainly revisit this if it becomes burdensome to maintain (or to get
> right).
My strong preference would be to have the full set of operations,
i.e. VREL_LTGT, VREL_{,UN}ORDERED, VREL_UN{LT,LE,GT,GE,EQ}, then everything
will fall out of this cleanly, not just some common special cases, but
also unions of them, intersections etc.
The only important question is if you want to differentiate VREL_*
for floating point comparisions with possible NANs vs. other comparisons
in the callers, then one needs effectively e.g. 2 sets of rr_* tables
in value-relation.cc and what exactly say VREL_EQ inverts to etc. is then
dependent on the context (this is what we do at the tree level normally,
e.g. fold-const.cc (invert_tree_comparison) has honor_nans argument),
or whether it would be a completely new set of value relations, so
even for EQ/NE etc. one would use VRELF_ or something similar.
Jakub
