[Bug tree-optimization/95489] New: Failure to optimize x && (x & y) to x & y

[Bug tree-optimization/95489] New: Failure to optimize x && (x & y) to x & y

[gabravier at gmail dot com]

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

            Bug ID: 95489
           Summary: Failure to optimize x && (x & y) to x & y
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int x, int y)
{
    return x && (x & y);
}

This can be optimized to `return x & y;` (see also the summary). This
optimization is done by LLVM, but not by GCC.

[Bug tree-optimization/95489] Failure to optimize x && (x & y) to x & y

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-06-03
           Keywords|                            |easyhack
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
phiopt1 sees

  <bb 2> :
  if (x_3(D) != 0)
    goto <bb 3>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 3> :
  _1 = x_3(D) & y_4(D);
  if (_1 != 0)
    goto <bb 5>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 4> :

  <bb 5> :
  # iftmp.0_2 = PHI <1(3), 0(4)>
  return iftmp.0_2;

and ifcombine_ifandif fails to combine the conditions via
maybe_fold_and_comparisons.  Via ifcombine we're looking also
at simplifying

  _tem1 = _1 != 0;
  _tem2 = x_3(D) != 0;
  _tem1 & _tem2

and thus

  (bit_and (ne (bit_and x_3 y_4) 0) (ne x_3 0))

where I'd say we miss

  (bit_and (ne @0 integer_zerop) (ne @1 integer_zerop))

->

  (ne (bit_and @0 @1) integer_zerop)

if @0 and @1 have compatible enough types.  That would probably do the
trick here.  Eventually works for generic equal values besides zero.
And also for bit_ior (but there only for special constants).

[Bug tree-optimization/95489] Failure to optimize x && (x & y) to x & y

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
>   (bit_and (ne (bit_and x_3 y_4) 0) (ne x_3 0))

This could be simplified

> where I'd say we miss
> 
>   (bit_and (ne @0 integer_zerop) (ne @1 integer_zerop))
> 
> ->
> 
>   (ne (bit_and @0 @1) integer_zerop)

This only seems possible for 1-bit types: 1!=0 & 2!0 is not (1&2)!=0

To me, this falls in the general category of (x!=a)?f(x):y where y happens to
be f(a) and f is not as costly as a condition+jump. I handled a few such cases
a while ago with neutral_element_p, but it could be much more general (I am not
saying it is easy).

[Bug tree-optimization/95489] Failure to optimize x && (x & y) to x & y

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
                 CC|                            |pinskia at gcc dot gnu.org

[Bug tree-optimization/95489] Failure to optimize x && (x & y) to x & y

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Almost exact dup of bug 88280, PR 88280 has more testcases.

*** This bug has been marked as a duplicate of bug 88280 ***