[Bug middle-end/111468] New: cannot express unordered equal in gimple FE

[Bug middle-end/111468] New: cannot express unordered equal in gimple FE

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111468

            Bug ID: 111468
           Summary: cannot express unordered equal in gimple FE
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aldyh at gcc dot gnu.org
  Target Milestone: ---

Created attachment 55930
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55930&action=edit
Failing testcase

It looks like you can't express an UNEQ_EXPR in the GIMPLE FE.

Am I missing something?  The snippet below compiles fine with:

  if (x_1 == a_5(D))

but not with:

  if (x_1 u== a_5(D))

And at least tree-pretty-print.cc has:

    case UNEQ_EXPR:
      return "u==";

I'm trying to come up with a threading test for some unordered stuff, and I'm
getting:

$ ./cc1 c.c -O2 -fgimple -quiet
c.c: In function ‘foo’:
c.c:19:10: error: expected ‘)’ before ‘u’
   19 |   if (x_1 u== a_5(D))
      |          ^~
      |          )

[snip snip]

Is there a blessed way of expressing unordered comparisons in the GIMPLE FE?

[Bug middle-end/111468] cannot express unordered equal in gimple FE

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111468

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Severity|normal                      |enhancement
   Last reconfirmed|                            |2023-09-19
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I was going to suggest to use __builtin_islessgreater but it does not exactly
work the same way.

That is:
```
void stuff();

void __GIMPLE (ssa,startwith("threadfull1"))
foo (float a, float b, int cond)
{
  float x;
  int _7;

 __BB(2):
  if (cond_3(D) != 0)
    goto __BB4;
  else
    goto __BB3;

 __BB(3):
  goto __BB4;

 __BB(4):
  x_1 = __PHI (__BB2: a_5(D), __BB3: b_4(D));
  _7 = __builtin_islessgreater (x_1 , a_5(D));
  if (_7 != 0)
    goto __BB5;
  else
    goto __BB6;

 __BB(5):
  stuff ();
  goto __BB6;

 __BB(6):
  return;

}
```

But we don't get UNEQ_EXPR right away, instead we have to wait until vrp1 to
get the UNEQ_EXPR ...

[Bug c/111468] cannot express unordered equal in gimple FE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111468

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
             Blocks|                            |101057
            Version|unknown                     |14.0
             Status|NEW                         |ASSIGNED

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm.  The "closest" we have is

static c_expr
c_parser_gimple_binary_expression (gimple_parser &parser)
{
...
    case CPP_NAME:
        {
          tree id = c_parser_peek_token (parser)->value;
          if (strcmp (IDENTIFIER_POINTER (id), "__MULT_HIGHPART") == 0)
            {
              code = MULT_HIGHPART_EXPR;

we can support the u== syntax or lean on the above and go with __UNEQ and
friends.  I'd probably go with __UNEQ.

diff --git a/gcc/c/gimple-parser.cc b/gcc/c/gimple-parser.cc
index cc3a8899d97..faf2def599f 100644
--- a/gcc/c/gimple-parser.cc
+++ b/gcc/c/gimple-parser.cc
@@ -1013,6 +1013,12 @@ c_parser_gimple_binary_expression (gimple_parser
&parser)
              code = MULT_HIGHPART_EXPR;
              break;
            }
+         else if (strcmp (IDENTIFIER_POINTER (id), "__UNEQ") == 0)
+           {
+             code = UNEQ_EXPR;
+             ret_type = truth_type_for (TREE_TYPE (lhs.value));
+             break;
+           }
        }
       /* Fallthru.  */
     default:

and

void stuff();

void __GIMPLE (ssa,startwith("threadfull1"))
foo (float a, float b, int cond)
{
  float x;
  _Bool _7;

 __BB(2):
  if (cond_3(D) != 0)
    goto __BB4;
  else
    goto __BB3;

 __BB(3):
  goto __BB4;

 __BB(4):
  x_1 = __PHI (__BB2: a_5(D), __BB3: b_4(D));
  _7 = x_1 __UNEQ a_5(D);
  if (_7 != _Literal (_Bool) 0)
    goto __BB5;
  else
    goto __BB6;

 __BB(5):
  stuff ();
  goto __BB6;

 __BB(6):
  return;

}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057
[Bug 101057] [gimplefe] GIMPLE frontend issues

[Bug c/111468] cannot express unordered equal in gimple FE

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111468

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:836e2cff7d9e4c06bf8ffd7e2df5dd134d8a22c2

commit r14-4127-g836e2cff7d9e4c06bf8ffd7e2df5dd134d8a22c2
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Sep 19 11:49:54 2023 +0200

    c/111468 - add unordered compare and pointer diff to GIMPLE FE parsing

    The following adds __UN{LT,LE,GT,GE,EQ}, __UNORDERED and __ORDERED
    operator parsing support and support for parsing - as POINTER_DIFF_EXPR.

            PR c/111468
    gcc/c/
            * gimple-parser.cc (c_parser_gimple_binary_expression): Add
            return type argument.
            (c_parser_gimple_statement): Adjust.
            (c_parser_gimple_paren_condition): Likewise.
            (c_parser_gimple_binary_expression): Use passed in return type,
            add support for - as POINTER_DIFF_EXPR, __UN{LT,LE,GT,GE,EQ},
            __UNORDERED and __ORDERED.

    gcc/testsuite/
            * gcc.dg/gimplefe-50.c: New testcase.
            * gcc.dg/gimplefe-51.c: Likewise.

[Bug c/111468] cannot express unordered equal in gimple FE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111468

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
   Target Milestone|---                         |14.0
         Resolution|---                         |FIXED

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk.

[Bug c/111468] cannot express unordered equal in gimple FE

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111468

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:f25960b03834712f312d46fed9a021df36f89f22

commit r14-4139-gf25960b03834712f312d46fed9a021df36f89f22
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Sep 19 13:18:51 2023 +0200

    c/111468 - dump unordered compare operators in their GIMPLE form with
-gimple

    The following adjusts -gimple dumping to dump the unordered compare ops
    and *h in their GIMPLE form.  It also adds parsing for __LTGT which I
    missed before.

            PR c/111468
    gcc/c/
            * gimple-parser.cc (c_parser_gimple_binary_expression): Handle
__LTGT.

    gcc/
            * tree-pretty-print.h (op_symbol_code): Add defaulted flags
            argument.
            * tree-pretty-print.cc (op_symbol): Likewise.
            (op_symbol_code): Print TDF_GIMPLE variant if requested.
            * gimple-pretty-print.cc (dump_binary_rhs): Pass flags to
            op_symbol_code.
            (dump_gimple_cond): Likewise.

    gcc/testsuite/
            * gcc.dg/gimplefe-50.c: Amend.

[Bug c/111468] cannot express unordered equal in gimple FE

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111468

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> Fixed on trunk.

Sweet.  Thanks so much.  This really helps.