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

["ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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.