[llvm-bugs] [Bug 36482] New: Missing rematerialization of a trival computation

[via llvm-bugs]

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

            Bug ID: 36482
           Summary: Missing rematerialization of a trival computation
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: eugeni.stepanov at gmail.com
                CC: llvm-bugs at lists.llvm.org

In the following example instead of rematerializing "add FP, #imm" after a
call, regalloc chooses to assign it to a callee-saved register, generating lots
of extra spills.

It appears that LLVM only ever remats COPY instructions (in RegisterCoalescer).
Is this a missing optimization? Where would it be implemented? LiveInterval
splitting in regalloc? In this case regalloc does not even attempt to split
because the function entry is not hot enough (RAGreedy::initializeCSRCost()
says that CSRCost == (5 / (1<<14)) ~== 0, so CSRs are free).

This is not AArch64-specific, very similar code is generated on X86.

$ cat 1.c
long p[6];

void use(long, long, long, long, long, long);

void f() {
  long base = (long)__builtin_frame_address(0);
  long a = base + 1;
  long b = base + 2;
  long c = base + 3;
  long d = base + 4;
  long e = base + 5;
  long f = base + 6;
  // Here a..f need to be in fixed, non-callee-saved regs, but they are also
  // used after the call. Prefer rematerialing to allocating a callee-save
  // register?
  use(a, b, c, d, e, f);
  p[0] = a;
  p[1] = b;
  p[2] = c;
  p[3] = d;
  p[4] = e;
  p[5] = f;
  return;
}

$ bin/clang 1.c -target aarch64-linux -O3 -c && bin/llvm-objdump -d -r 1.o
f:
       0:       f8 5f bc a9     stp     x24, x23, [sp, #-64]!
       4:       fd 7b 03 a9     stp     x29, x30, [sp, #48]
       8:       fd c3 00 91     add     x29, sp, #48
       c:       a0 07 00 91     add     x0, x29, #1
      10:       a1 0b 00 91     add     x1, x29, #2
      14:       a2 0f 00 91     add     x2, x29, #3
      18:       a3 13 00 91     add     x3, x29, #4
      1c:       a4 17 00 91     add     x4, x29, #5
      20:       a5 1b 00 91     add     x5, x29, #6
      24:       f6 57 01 a9     stp     x22, x21, [sp, #16]
      28:       f4 4f 02 a9     stp     x20, x19, [sp, #32]
      2c:       b3 07 00 91     add     x19, x29, #1
      30:       b4 0b 00 91     add     x20, x29, #2
      34:       b5 0f 00 91     add     x21, x29, #3
      38:       b6 13 00 91     add     x22, x29, #4
      3c:       b7 17 00 91     add     x23, x29, #5
      40:       b8 1b 00 91     add     x24, x29, #6
      44:       00 00 00 94     bl      #0
                0000000000000044:  R_AARCH64_CALL26     use
      48:       08 00 00 90     adrp    x8, #0
                0000000000000048:  R_AARCH64_ADR_PREL_PG_HI21   p
      4c:       08 01 00 91     add     x8, x8, #0
                000000000000004c:  R_AARCH64_ADD_ABS_LO12_NC    p
      50:       13 51 00 a9     stp     x19, x20, [x8]
      54:       15 59 01 a9     stp     x21, x22, [x8, #16]
      58:       fd 7b 43 a9     ldp     x29, x30, [sp, #48]
      5c:       f4 4f 42 a9     ldp     x20, x19, [sp, #32]
      60:       f6 57 41 a9     ldp     x22, x21, [sp, #16]
      64:       17 61 02 a9     stp     x23, x24, [x8, #32]
      68:       f8 5f c4 a8     ldp     x24, x23, [sp], #64
      6c:       c0 03 5f d6     ret

-- 
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/20180223/0fd7c819/attachment-0001.html>