<html>
<head>
<base href="http://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 - X86FrameLowering::emitSPUpdate generates inefficient code for epilogues with very large stacks."
href="http://bugs.llvm.org/show_bug.cgi?id=31962">31962</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>X86FrameLowering::emitSPUpdate generates inefficient code for epilogues with very large stacks.
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>simon.dardis@imgtec.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>The following code generates inefficient stack updates for the epilogue on X86:
int main(void) {
int x[600000000];
return 0;
}
When compiled for 'x86_64-apple-darwin15.2.0', generates the following:
movabsq $2399999888, %rax # imm = 0x8F0D1790
subq %rax, %rsp
xorl %eax, %eax
movl $0, -4(%rbp)
addq $2147483647, %rsp # imm = 0x7FFFFFFF
addq $252516241, %rsp # imm = 0xF0D1791
popq %rbp
retq
Tracing the behaviour of emitEpilogue shows that MBBI ends up pointing at
POP64r when emitSPUpdate is called. emitSPUpdate in turn calls
findDeadCallerSavedReg which attempts to match MBBI against the X86 backend's
return instructions. Since MBBI is pointing to POP64r, no register is found, so
multiple addqs are generated to perform the stack pointer update.
I found this bug report on HN with the following code:
#include <stdint.h>
int main(void) {
int x[SIZE_MAX / 32];
return 0;
}
Which on my machine caused clang to consume 8+ gigabytes of memory before I
terminated it. I reduced to it to the first example.
That code can be compiled with -momit-leaf-frame-pointer -fno-stack-protector
for 'x86_64-apple-darwin15.2.0' but without the pair of those options, llvm
appears to be trying to generate large amounts of addq instructions.
Thanks to bluetomcat for reporting the issue!</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>