Hi Jakub.

I wasn't ignoring you, just quietly thinking, making sure we weren't
missing anything.  In the process I cleaned everything, which
hopefully makes it easier to see why we don't need relationals (the
key is to look at frelop_early_resolve() and the op1/op2_range entries
which clear the NAN bits).

I am committing the patch below, and as I say in it:

    I don't mean this patch as a hard-no against implementing the
    unordered relations Jakub preferred, but seeing that it's looking
    cleaner and trivially simple without the added burden of more enums,
    I'd like to flesh it out completely and then discuss if we still think
    new codes are needed.  At least now we have tests :).

Please let me know if you have any test cases you think we may be
missing.  FYI, I'm still not done with the unordered folders.

Tested on x86-64 Linux.  Committed.
Aldy

On Mon, Aug 28, 2023 at 3:01 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> 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
>