[llvm-bugs] [Bug 46066] New: Register allocation does not keep loop-incremented variables in same register, leading to unnecessary register-to-register copies

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46066

            Bug ID: 46066
           Summary: Register allocation does not keep loop-incremented
                    variables in same register, leading to unnecessary
                    register-to-register copies
           Product: new-bugs
           Version: 10.0
          Hardware: Other
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: heikki.kultala at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Created attachment 23529
  --> https://bugs.llvm.org/attachment.cgi?id=23529&action=edit
C code causing this inefficient code generation

It would seem that the default register allocator is really bad at keeping
variables that are incremented inside loop in the same register, causing lots
of extra register-to-register copies.

C Code:

extern short* A;
extern short* B;
extern short* C;
extern short* end;

int main(void) {
    short* a = A;
    short* b = B;
    short* c = C;
    do {
         *a++ = *b++ + *c++;
    } while (b != end);
}

The assembly of the loop, compiled to riscv32 with -O3 becomes:

        lh      a4, 0(a2) 
        lh      a5, 0(a3)
        addi    a1, a2, 2 # this stupidly changes register of the value
        addi    a3, a3, 2
        add     a2, a5, a4
        addi    a4, a0, 2 # this stupidly changes register of the value
        sh      a2, 0(a0)
        add     a0, zero, a4 # unnecessary register-to-register move
        add     a2, zero, a1 # unnecessary register-to-register move
        bne     a6, a1, .LBB0_1

If the pointers would always stay in the same registers(a0, a2, a3), the code
would be 2 instructions shorter:

        lh      a4, 0(a2)
        lh      a5, 0(a3)
        addi    a2, a2, 2
        addi    a3, a3, 2
        add     a1, a5, a4
        sh      a1, 0(a0)
        addi    a0, a0, 2 # this gets moved after the store due WaR
        bne     a6, a2, .LBB0_1


I have encountered the same effect on some other architectures too, but this
case with risc-v was the most clear one, so using this as the example.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200525/c733e742/attachment.html>