[Bug rtl-optimization/107455] New: Suboptimal codegen for some branch-on-zero cases

[Bug rtl-optimization/107455] New: Suboptimal codegen for some branch-on-zero cases

[sinan.lin at linux dot alibaba.com]

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

            Bug ID: 107455
           Summary: Suboptimal codegen for some branch-on-zero cases
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sinan.lin at linux dot alibaba.com
  Target Milestone: ---

Created attachment 53788
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53788&action=edit
code sequence from https://github.com/embench/embench-iot

gcc -S -Os -march=rv32gc -mabi=ilp32 test.c


```
sglib_dllist_len:
        beq     a0,zero,.L6
        mv      a4,a0
        li      a5,0
.L3:
        lw      a4,8(a4)
        addi    a5,a5,1
        bne     a4,zero,.L3
        lw      a4,4(a0)
        li      a0,0
.L4:
        bne     a4,zero,.L5
        add     a0,a0,a5
        ret
.L5:
        lw      a4,4(a4)
        addi    a0,a0,1
        j       .L4
.L6:
        li      a0,0
        ret
```

li a0,0 is unnecessary, and this extra instruction might lead to a worse cfg
and bad code size. I spotted several size suboptimal cases related to this
pattern.


result on clang:
```
sglib_dllist_len:
        beqz    a0, .LBB0_4
        mv      a1, a0
        li      a0, -1
        mv      a2, a1
.LBB0_2:
        lw      a2, 8(a2)
        addi    a0, a0, 1
        bnez    a2, .LBB0_2
.LBB0_3:
        lw      a1, 4(a1)
        addi    a0, a0, 1
        bnez    a1, .LBB0_3
.LBB0_4:
        ret
```

Similar problem on arm64: https://godbolt.org/z/Yo6jsKMGz

[Bug rtl-optimization/107455] Suboptimal codegen for some branch-on-zero cases

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
           Severity|normal                      |enhancement

[Bug rtl-optimization/107455] Suboptimal codegen for some branch-on-zero cases

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-10-29
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Interesting that powerpc64le with clang is much much worse than aarch64. I
would assume they would have a similar code generation. GCC produces similar
for aarch64 and powerpc64le and riscv.

Confirmed. There might be other bugs recording a similar thing.

[Bug rtl-optimization/107455] Suboptimal codegen for some branch-on-zero cases

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note GCC does this optimization at the gimple level some of the times when it
comes to the same type.
Witness:
int x (int t)
{
  if (t & 256)
    return -26;
  return 0;
}

[Bug rtl-optimization/107455] Suboptimal codegen for some branch-on-zero cases

[law at gcc dot gnu.org]

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

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org

--- Comment #3 from Jeffrey A. Law <law at gcc dot gnu.org> ---
This looks like the problem I was chasing down a month or so ago.  I've
actually got all the review comments addressed and just need to resubmit.

Basically what we need is to take advantage of conditional equivalences
post-reload.