<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Missing rematerialization of a trival computation"
href="https://bugs.llvm.org/show_bug.cgi?id=36482">36482</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Missing rematerialization of a trival computation
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Common Code Generator Code
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>eugeni.stepanov@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>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</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>