https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113423
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Target| |x86_64-linux-gnu powerpc
Component|tree-optimization |rtl-optimization
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The GIMPLE level looks fine:
```
if (b.0_1 != 0B)
goto <bb 4>; [70.00%]
else
goto <bb 3>; [30.00%]
<bb 3> [local count: 322122544]:
pretmp_7 = c;
goto <bb 5>; [100.00%]
<bb 4> [local count: 751619280]:
c = 3;
<bb 5> [local count: 1073741824]:
# prephitmp_8 = PHI <pretmp_7(3), 3(4)>
```
Even on aarch64 it looks good:
```
foo:
.LFB0:
.cfi_startproc
adrp x1, .LANCHOR0
add x0, x1, :lo12:.LANCHOR0
ldr x1, [x1, #:lo12:.LANCHOR0]
cbz x1, .L5
mov w1, 3
mov w2, w1
str w1, [x0, 8]
str w2, [x0, 12]
ret
.p2align 2,,3
.L5:
ldr w2, [x0, 8]
str w2, [x0, 12]
ret
```
No extra load.
PowerPC (32bit) looks similar to x86_64 though:
```
foo:
.LFB0:
.cfi_startproc
lis 9,b@ha
lwz 9,b@l(9)
cmpwi 0,9,0
lis 9,c@ha
lwz 10,c@l(9)
beq 0,.L3
li 10,3
stw 10,c@l(9)
.L3:
lis 9,a@ha
stw 10,a@l(9)
blr
```
Post RA IFCVT is doing the change:
```
IF-CASE-1 found, start 2, then 3
rescanning insn with uid = 10.
changing bb of uid 14
from 3 to 2
deleting insn with uid = 35.
deleting block 3
Conversion succeeded on pass 1.
```
It is doing it because of heurstics due to GCC handles `!=0`/`==0` comparisons
as being taken towards the `!=0` case. E.g. if you change the comparison
against b to be `b == 300`, you get different behavior.
