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

            Bug ID: 110423
           Summary: Redundant constants not gettign eliminated on RISCV.
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vineetg at gcc dot gnu.org
  Target Milestone: ---

Redundant constants, across basic blocks, don't seem to be eliminated robustly
by gcc. I'd reported this last year [1] and this is just recapturing that info
as a bugzilla PR.

[1] https://gcc.gnu.org/pipermail/gcc/2022-October/239645.html

When analyzing coremark build for RISC-V, noticed redundant constants 
not being eliminated. While this is a recurrent issue with RV, this 
specific instance is not unique to RV as I can trigger similar output on 
aarch64 with -fno-if-conversion, hence something which could be 
addressed in common passes.

-O3 -march=rv64gc_zba_zbb

crcu8:
        xor     a3,a0,a1
        andi    a3,a3,1
        srli    a4,a0,1
        srli    a5,a1,1
        beq     a3,zero,.L2

        li      a3,-24576       # 0xFFFF_A000
        addi    a3,a3,1         # 0xFFFF_A001
        xor     a5,a5,a3
        zext.h  a5,a5

.L2:
        xor     a4,a4,a5        
        andi    a4,a4,1 
        srli    a3,a0,2 
        srli    a5,a5,1 
        beq     a4,zero,.L3     

        li      a4,-24576       # 0xFFFF_A000
        addi    a4,a4,1         # 0xFFFF_A001
        xor     a5,a5,a4        
        zext.h  a5,a5           

.L3:
        xor     a3,a3,a5        
        andi    a3,a3,1 
        srli    a4,a0,3 
        srli    a5,a5,1 
        beq     a3,zero,.L4

        li      a3,-24576       # 0xFFFF_A000
        addi    a3,a3,1         # 0xFFFF_A001
[...]

.L8
        andi    a3,a5,1
        srli    a0,a5,1
        beq     a3,a4,.L9
        li      a5,-24576       # 0xFFFF_A000
        addi    a5,a5,1         # 0xFFFF_A001
        xor     a0,a0,a5
        slli    a0,a0,48
        srli    a0,a0,48
.L9:
        ret


cse can't handle this: as explained by Jeff in [2] EBB can have jumps out but
not jumps in, which misses the cfg paths needed to be traversed to find the
equivalents.

[2] https://gcc.gnu.org/pipermail/gcc/2022-October/239646.html

Note that since gcc 13.1, this specific test generates different code since the
match.pd change 6508d5e5a1a ("match.pd: rewrite select to branchless
expression") now removes the branches and the arithmatic needing the large
const. 
But this test is very convenient, so I'm continuing to use it and just revert
the match.pd change in my local gcc build.

Reply via email to