[Bug tree-optimization/112659] New: missed-optimization: if (exp) return exp; else return 0;

[Bug tree-optimization/112659] New: missed-optimization: if (exp) return exp; else return 0;

[goon.pri.low at gmail dot com]

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

            Bug ID: 112659
           Summary: missed-optimization: if (exp) return exp; else return
                    0;
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: goon.pri.low at gmail dot com
  Target Milestone: ---

This code here:

int unopt(int v) {
    if (v + 8)
        return v + 8;
    else
        return 0;
}

unopt:
        xor     edx, edx
        lea     eax, [rdi+8]
        cmp     edi, -8
        cmove   eax, edx
        ret

Could be optimized to:

int opt(int v) {
    return v + 8;
}

opt:
        lea     eax, [rdi+8]
        ret

Note: this happens for all operators, not just addition!
Also, have any suggestions for a better bug name? I am better at spotting
optimizations, not naming them.

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Severity|normal                      |enhancement
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2023-11-21

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Mine.

We get in phiopt1:
        v_2(D) == -8 ? 0 : _4
where _4 is defined as:
  _4 = v_2(D) + 8;

So maybe
```
(simplify
 (cond (eq @0 INTEGER_CST@1) zero_p (plus@3 @0 INTEGER_CST@2))
 @3
)
```


Note GCC handles already on the trunk:
```
int optb(int v, int b) {
    if (v -b)
        return v - b;
    else
        return 0;
}
int optc(int v, int b) {
    if (v + b)
        return v + b;
    else
        return 0;
}
```

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=19832

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>Note: this happens for all operators, not just addition!

Actually it is just addition with a constant on the trunk.
```
int g(int v, int b) {
    if (v - b)
        return v - b ;
    else
        return 0;
}
```
was handled with PR 19832.


I see division with a constant is not handled though:
```
int unopt(int v, int b) {
    if (v /2)
        return v / 2;
    else
        return 0;
}
```

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> So maybe
> ```
> (simplify
>  (cond (eq @0 INTEGER_CST@1) zero_p (plus@3 @0 INTEGER_CST@2))
>  @3
> )
> ```

Whoops I forgot the check `wi::to_wide(@1) == -wi::to_wide(@2)` there :).

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

[goon.pri.low at gmail dot com]

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

--- Comment #4 from gooncreeper <goon.pri.low at gmail dot com> ---
(In reply to Andrew Pinski from comment #2)
> >Note: this happens for all operators, not just addition!
> 
> Actually it is just addition with a constant on the trunk.
> ```
> int g(int v, int b) {
>     if (v - b)
>         return v - b ;
>     else
>         return 0;
> }
> ```
> was handled with PR 19832.
> 
> 
> I see division with a constant is not handled though:
> ```
> int unopt(int v, int b) {
>     if (v /2)
>         return v / 2;
>     else
>         return 0;
> }
> ```


I am not quite testing on the trunk build but I also believe modulo

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to gooncreeper from comment #4)
> I am not quite testing on the trunk build but I also believe modulo

Yes but only powers of 2. Due to the conversions to using &.

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Vector testcase (C++ only) for the missing add case:
```
#define vector4 __attribute__((vector_size(4*sizeof(int))))

void unopt(vector4 int *v) {
    vector4 int t = *v;
    vector4 int t1 = t + 8;
    *v = (t != -8) ? (t1) : 0;
}
```

Adding it here so I don't lose it (note clang/LLVM does catch it already).

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is the pattern I added for the plus case:
```
(for cnd (cond vec_cond)
...
 /* (a != CST1) ? (a + CST2) : 0 -> (a + CST2) iff CST1 == -CST2 */
 (simplify
  (cnd (ne @0 uniform_integer_cst_p@1)
       (plus@3 @0 uniform_integer_cst_p@2)
       integer_zerop)
  (if (wi::to_wide (uniform_integer_cst_p (@1))
       == -wi::to_wide (uniform_integer_cst_p (@2)))
   @3))
)
```

The division one is harder, I think I might only handle unsigned. Or maybe
decide that division is not a good idea to do ...

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #7)
> This is the pattern I added for the plus case:
> ```
> (for cnd (cond vec_cond)
> ...
>  /* (a != CST1) ? (a + CST2) : 0 -> (a + CST2) iff CST1 == -CST2 */
>  (simplify
>   (cnd (ne @0 uniform_integer_cst_p@1)
>        (plus@3 @0 uniform_integer_cst_p@2)
>        integer_zerop)
>   (if (wi::to_wide (uniform_integer_cst_p (@1))
>        == -wi::to_wide (uniform_integer_cst_p (@2)))
>    @3))
> )
> ```

Thinking about this slightly more, we should be able to handle (which LLVM does
not currently handles):
```
int optb(int v, int b) {
  // b = 8;
    if (v != -b)
        return v + b;
    else
        return 0;
}
```

too. Which means this is similar to PR 113265. So I should fix PR 113265 first
and then add the pattern for this case.

[Bug tree-optimization/112659] missed-optimization: if (exp) return exp; else return 0;

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #8)
> Thinking about this slightly more, we should be able to handle (which LLVM
> does not currently handles):
> ```
> int optb(int v, int b) {
>   // b = 8;
>     if (v != -b)
>         return v + b;
>     else
>         return 0;
> }
> ```

Oh that was recorded as PR 114204 .