[Bug tree-optimization/110992] New: [14 Regression] Dead Code Elimination Regression at -O3 since r14-1654-g7ceed7e3e29

[Bug tree-optimization/110992] New: [14 Regression] Dead Code Elimination Regression at -O3 since r14-1654-g7ceed7e3e29

[scherrer.sv at gmail dot com]

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

            Bug ID: 110992
           Summary: [14 Regression] Dead Code Elimination Regression at
                    -O3 since r14-1654-g7ceed7e3e29
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: scherrer.sv at gmail dot com
  Target Milestone: ---

static unsigned b;
static short c = 4;
void foo(void);
static short(a)(short d, short g) { return d * g; }
void e();
static char f() {
  b = 0;
  return 0;
}
int main() {
  int h = b;
  if ((short)(a(c && e, 65535) & h)) {
    foo();
    h || f();
  }
}

gcc-bcda361daae (trunk) -O3 cannot eliminate the call to foo but
gcc-releases/gcc-13.1.0 -O3 can.
-----------------------------------------------------------------------
gcc-bcda361daaec8623c91d0dff3ea8e576373b5f50 -O3 case.c -S -o case.s
--------- OUTPUT ---------
main:
.LFB2:
        .cfi_startproc
        cmpw    $0, b(%rip)
        jne     .L8
        xorl    %eax, %eax
        ret
.L8:
        pushq   %rax
        .cfi_def_cfa_offset 16
        call    foo
        xorl    %eax, %eax
        popq    %rdx
        .cfi_def_cfa_offset 8
        ret
---------- END OUTPUT ---------

-----------------------------------------------------------------------
gcc-2b98cc24d6af0432a74f6dad1c722ce21c1f7458 -O3 case.c -S -o case.s
--------- OUTPUT ---------
main:
.LFB2:
        .cfi_startproc
        xorl    %eax, %eax
        ret
---------- END OUTPUT ---------

-----------------------------------------------------------------------
Bisects to r14-1654-g7ceed7e3e29

[Bug tree-optimization/110992] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1654-g7ceed7e3e29

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-08-11
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed the problem is ethread is not able to do the jump threading with the
new IR:
```
Checking profitability of path (backwards):  bb:3 (3 insns) bb:2
  Control statement insns: 2
  Overall: 1 insns

 Registering killing_def (path_oracle) b.0_1
 Registering killing_def (path_oracle) _7
 Registering killing_def (path_oracle) _6
 Registering killing_def (path_oracle) _25
 Registering killing_def (path_oracle) _3
 Registering killing_def (path_oracle) c.1_2
path: 2->3->xx REJECTED
```

I don't understand why though ...

[Bug tree-optimization/110992] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1654-g7ceed7e3e29

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So I think this is because ethread can understand `(a & b)!=0` but not
`(a*c)!=0` that is a*c != 0 means that a or c will both be non-zero (especially
since a*c is known to not to overflow as c as a range of [0,1]).

[Bug tree-optimization/110992] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1654-g7ceed7e3e29

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So this was fixed by accident via r14-3721-ge6bcf83989478348428c732 .

[Bug tree-optimization/110992] [14 Regression] Dead Code Elimination Regression at -O3 since r14-1654-g7ceed7e3e29

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
What we had before in GCC 13:
  # RANGE [irange] unsigned short [0, 1] NONZERO 0x1
  d.3_19 = (unsigned short) _3;
  _21 = -d.3_19;
  _22 = (short intD.17) _21;
  _6 = (short intD.17) b.0_1;
  _7 = _6 & _22;

Which then after  r14-1654-g7ceed7e3e29 gives us:
 _t = (short intD.17) d.3_19
 _7 = _6 * _t

What we get after that match patch:
  _3 = c.1_2 != 0;
  _25 = (short intD.17) _3;
  _22 = -_25;
  _6 = (short intD.17) b.0_1;
  _7 = _6 & _22;

That is we lose the range information.
If I add this to match.pd:
```
diff --git a/gcc/match.pd b/gcc/match.pd
index 97db0eb5f25..e68e2c57e25 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2181,6 +2181,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
       && (TYPE_UNSIGNED (type)
          || TYPE_PRECISION (type) > 1))))

+(match zero_one_valued_p
+ (convert@0 zero_one_valued_p@1))
+
 /* Transform { 0 or 1 } * { 0 or 1 } into { 0 or 1 } & { 0 or 1 }.  */
 (simplify
  (mult zero_one_valued_p@0 zero_one_valued_p@1)

```

Then this fails again.
I am thinking about adding this anyways so I am going to keep this one open.

[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|14.0                        |13.3
            Summary|[14 Regression] Dead Code   |[13/14 Regression] missed
                   |Elimination Regression at   |VRP optimization due to
                   |-O3 since                   |transformation of `a &
                   |r14-1654-g7ceed7e3e29       |-zero_one_valued_p` into `a
                   |                            |* zero_one_valued_p`

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm, I think this is a ranger issue really.
Take:
```
int f(unsigned b, short c)
{
  int bt = b;
  int bt1 = bt;
  int t = bt1 & -(c!=0);
 // int t = bt1 * (c!=0);

  if (!t) return 0;
  foo(bt == 0);
  return 0;
}
```

That `bt == 0` should be figured out that is 0 there. We could figure that out
in GCC 12 even. But in GCC 13+ we could not.

That is traced back to r13-793-g8fb94fc6097c but really the ranger should
figure out if you have a*b != 0, then both a and b should be non-zero ...
But currently that is not support ....
It looks like we only handle `a & b` that way ...

[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
One way of fixing this is:
/* Transform (a * { 0 or 1 }) !=/== 0 into (a & { 0 or 1 }) !=/== 0.  */
(for cmp (ne eq)
 (simplify
  (cmp (mult:cs @0 zero_one_valued_p@1) integer_zerop@2)
  (cmp (bit_and @0 @1) @2)))

That is (a*zero_one_valued_p)!=0 transform it into (a & zero_one_valued_p) != 0
if the multiply was single use.

That is how I am going to fix this.

[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Actually we should transform it into
((convert)zero_one_valued_p) & (a != 0)

Or ^1 for the == 0 case ...

This should allow for better code I think.

[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #7)
> Actually we should transform it into
> ((convert)zero_one_valued_p) & (a != 0)
> 
> Or ^1 for the == 0 case ...
> 
> This should allow for better code I think.

Or better yet:
(((Convert)cmp) & b) != 0
Into cmp & (b!=0)

Icmp for == 0.
Now I have seen that before too.

[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is what I have so far:
/* Transform (a * { 0 or 1 }) != 0 into {0 or 1} != 0 & (a != 0) */
/* Transform (a * { 0 or 1 }) == 0 into ({0 or 1} == 0) | (a == 0) */
(for cmp (ne eq)
     bit_op (bit_and bit_ior)
 (simplify
  (cmp (mult:cs @0 zero_one_valued_p@1) integer_zerop@2)
  (bit_op (cmp @1 { build_zero_cst (TREE_TYPE (@1)); })
          (cmp @0 @2))))

/* zero_one_valued_p != 0 -> (cast)zero_one_valued_p */
(simplify
 (ne zero_one_valued_p@0 integer_zerop)
 (convert @0))

[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is what I came up with in the end:
/* (a * b@[0,1]) == CST
     -> 
       CST == 0 ? (a == CST | b == 0) : (a == CST & b != 0)
   (a * b@[0,1]) != CST
     -> 
       CST != 0 ? (a != CST | b == 0) : (a != CST & b != 0)  */
(for cmp (ne eq)
 (simplify
  (cmp (mult:cs @0 zero_one_valued_p@1) INTEGER_CST@2)
  (if ((cmp == EQ_EXPR) ^ (wi::to_wide (@2) != 0))
   (bit_ior
    (cmp @0 @2)
    (convert (bit_xor @1 { build_one_cst (TREE_TYPE (@1)); })))
   (bit_and (cmp @0 @2) (convert @1)))))


This allows more than just CST == 0 even. I will write up some testcases now
...

[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2023-Septemb
                   |                            |er/630651.html

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630651.html

[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|https://gcc.gnu.org/piperma |
                   |il/gcc-patches/2023-Septemb |
                   |er/630651.html              |
             Status|ASSIGNED                    |NEW
           Keywords|patch                       |
           Assignee|pinskia at gcc dot gnu.org         |unassigned at gcc dot gnu.org

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Not working on this. a Ranger/VRP person should fix this instead ...

[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org
           Priority|P3                          |P2

[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rzinsly at ventanamicro dot com

--- Comment #13 from Jeffrey A. Law <law at gcc dot gnu.org> ---
So like the other bug involving multiplies against objects with a known range
[0,1], we should very seriously consider turning the multiply into a
conditional move.  ie x * b where b is known to have the range [0,1] we can
turn that into

dest = b ? x : 0

Some processors that don't have generalized conditional moves do have
conditional zero instructions.  ie, zicond on RISC-V.

[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=111126

--- Comment #14 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #13)
> So like the other bug involving multiplies against objects with a known
> range [0,1], we should very seriously consider turning the multiply into a
> conditional move.  ie x * b where b is known to have the range [0,1] we can
> turn that into
> 
> dest = b ? x : 0
> 
> Some processors that don't have generalized conditional moves do have
> conditional zero instructions.  ie, zicond on RISC-V.

It's PR111126.