[Bug tree-optimization/113423] New: Missed Optimization: potential redundant load

[Bug tree-optimization/113423] New: Missed Optimization: potential redundant load

[carnet at student dot ethz.ch]

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

            Bug ID: 113423
           Summary: Missed Optimization: potential redundant load
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: carnet at student dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/jbbEPePhv

Source Code:
int a;
int *b;
int c = 0;

void foo() {
  if (b)
    c = 3;
  a = c;
}


int bar(){
    return c;
}

foo:
        cmpq    $0, b(%rip)
        movl    c(%rip), %eax <========= eax is overwritten when the jump is
not taken, potentially redundant load
        je      .L3
        movl    $3, c(%rip) 
        movl    $3, %eax
.L3:
        movl    %eax, a(%rip)
        ret


%eax is written before the branch. If the branch is not taken, eax is
overwritten. Which makes the highlighted load potentially unnecessary.

[Bug rtl-optimization/113423] Missed Optimization: potential redundant load

[pinskia at gcc dot gnu.org]

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.