[Bug rtl-optimization/108826] New: Inefficient address generation on POWER and RISC-V

["tkoenig at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 108826
           Summary: Inefficient address generation on POWER and RISC-V
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

For the code (reduced from embench)

struct {
  unsigned int table[4][100];
} * _nettle_aes_decrypt_T;
unsigned int _nettle_aes_decrypt_w1;
void _nettle_aes_decrypt() {
  _nettle_aes_decrypt_T->table[2][0] =
      _nettle_aes_decrypt_T->table[2][_nettle_aes_decrypt_w1 >> 6 & 5];
}

current trunk generates

0:      addis 2,12,.TOC.-.LCF0@ha
        addi 2,2,.TOC.-.LCF0@l
        .localentry     _nettle_aes_decrypt,.-_nettle_aes_decrypt
        addis 9,2,.LANCHOR0+8@toc@ha
        lwz 9,.LANCHOR0+8@toc@l(9)
        addis 10,2,.LANCHOR0@toc@ha
        ld 10,.LANCHOR0@toc@l(10)
        srwi 9,9,6
        andi. 9,9,0x5
        addi 9,9,200
        sldi 9,9,2
        lwzx 9,10,9
        stw 9,800(10)
        blr

After the TOC loading, this shifts the value once, does the and, adds 200
and then shifts back the value. These two shifts are not necessary.

A better alternative would be something like (please excuse any errors)

        srwi 9,9,4
        andi 9,9,20
        add  9,9,2
        lwz  9,800(9)
        stw  9,800(9)

saving an instruction.

RISC-V does something similar.  According to godbolt:

        lui     a5,%hi(_nettle_aes_decrypt_w1)
        lw      a5,%lo(_nettle_aes_decrypt_w1)(a5)
        lui     a4,%hi(_nettle_aes_decrypt_T)
        ld      a4,%lo(_nettle_aes_decrypt_T)(a4)
        srliw   a5,a5,6
        andi    a5,a5,5
        addi    a5,a5,200
        slli    a5,a5,2
        add     a5,a4,a5
        lw      a5,0(a5)
        sw      a5,800(a4)
        ret


(which is why I think this is a general RTL optimization issue).
x86 is much better:

        movl    _nettle_aes_decrypt_w1(%rip), %eax
        movq    _nettle_aes_decrypt_T(%rip), %rdx
        shrl    $6, %eax
        andl    $5, %eax
        movl    800(%rdx,%rax,4), %eax
        movl    %eax, 800(%rdx)
        ret

but it can use the complex addressing modes on x86.