[Bug rtl-optimization/94838] New: Failure to optimize out useless zero-ing after register was already zero-ed

[Bug rtl-optimization/94838] New: Failure to optimize out useless zero-ing after register was already zero-ed

[gabravier at gmail dot com]

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

            Bug ID: 94838
           Summary: Failure to optimize out useless zero-ing after
                    register was already zero-ed
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(bool b, int *p)
{
    return b && *p;
}

GCC generates this with -O3:

f(bool, int*):
  xor eax, eax
  test dil, dil
  je .L1
  mov edx, DWORD PTR [rsi]
  xor eax, eax ; This can be removed, since eax is already 0 here
  test edx, edx
  setne al
.L1:
  ret

[Bug target/94838] Failure to optimize out useless zero-ing after register was already zero-ed

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Most likely it is due to splitting of the setting of eax from the cmp happens
after reload.  THIS IS a target issue because of that.

[Bug target/94838] Failure to optimize out useless zero-ing after register was already zero-ed

[gabravier at gmail dot com]

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

Gabriel Ravier <gabravier at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|x86_64-linux-gnu            |x86_64-* i?86-*-*

--- Comment #2 from Gabriel Ravier <gabravier at gmail dot com> ---
This also occurs on i68* : 

f(bool, int*):
  xor eax, eax ; Already 0
  cmp BYTE PTR [esp+4], 0
  je .L1
  mov eax, DWORD PTR [esp+8] ; Could use different caller-saved register such
as ecx or edx
  mov eax, DWORD PTR [eax]
  test eax, eax
  setne al
  movzx eax, al
.L1:
  ret

[Bug target/94838] Failure to optimize out useless zero-ing after register was already zero-ed

[gabravier at gmail dot com]

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

--- Comment #3 from Gabriel Ravier <gabravier at gmail dot com> ---
This also occurs on i68* : 

f(bool, int*):
  xor eax, eax ; Already 0
  cmp BYTE PTR [esp+4], 0
  je .L1
  mov eax, DWORD PTR [esp+8] ; Could use different caller-saved register such
as ecx or edx
  mov eax, DWORD PTR [eax]
  test eax, eax
  setne al
  movzx eax, al ; This could then be avoided since eax would already be 0
.L1:
  ret

[Bug target/94838] Failure to optimize out useless zero-ing after register was already zero-ed

[gabravier at gmail dot com]

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

--- Comment #4 from Gabriel Ravier <gabravier at gmail dot com> ---
Oops, seems like there was a weird collision. Don't pay attention to the second
to last comment before this one, it's identical to the last comment before this
one except for a single comment being added in the last comment before this
one.

[Bug target/94838] Failure to optimize out useless zero-ing after register was already zero-ed

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-04-29
             Status|UNCONFIRMED                 |NEW

[Bug rtl-optimization/94838] Failure to optimize out useless zero-ing after register was already zero-ed

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |rtl-optimization

--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Gabriel Ravier from comment #0)
> int f(bool b, int *p)
> {
>     return b && *p;
> }
> 
> GCC generates this with -O3:
> 
> f(bool, int*):
>   xor eax, eax
>   test dil, dil
>   je .L1
>   mov edx, DWORD PTR [rsi]
>   xor eax, eax ; This can be removed, since eax is already 0 here
>   test edx, edx
>   setne al
> .L1:
>   ret

The first xor is return value load and the second is from peephole2 pass that
converts:

   11: NOTE_INSN_BASIC_BLOCK 3
   12: flags:CCZ=cmp([si:DI],0)
      REG_DEAD si:DI
   13: NOTE_INSN_DELETED
   32: ax:QI=flags:CCZ!=0
      REG_DEAD flags:CCZ
   33: ax:SI=zero_extend(ax:QI)

to:

   11: NOTE_INSN_BASIC_BLOCK 3
   40: {ax:SI=0;clobber flags:CC;}
   43: dx:SI=[si:DI]
   44: flags:CCZ=cmp(dx:SI,0)
   42: strict_low_part(ax:QI)=flags:CCZ!=0

The follow-up cprop-hardreg pass does not notice that we already have zero
loaded to a register.

There is nothing that target-dependent part can do here. A follow-up RTL
hardreg propagation pass should fix this.