<html>
<head>
<base href="https://llvm.org/bugs/" />
</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 --- - r210828 (GVN: Enable value forwarding for calloc) can cause absurdly long compile times"
href="https://llvm.org/bugs/show_bug.cgi?id=27308">27308</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>r210828 (GVN: Enable value forwarding for calloc) can cause absurdly long compile times
</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>dimitry@andric.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=16199" name="attach_16199" title="Test case for r210828 regression in compile time">attachment 16199</a> <a href="attachment.cgi?id=16199&action=edit" title="Test case for r210828 regression in compile time">[details]</a></span>
Test case for r210828 regression in compile time
A recent Mesa update in FreeBSD caused a seemingly hanging instance of clang
for me, when it was compiling a rather large generated .c file (generated by
<a href="https://cgit.freedesktop.org/mesa/mesa/tree/src/mapi/glapi/gen/gl_gentable.py">https://cgit.freedesktop.org/mesa/mesa/tree/src/mapi/glapi/gen/gl_gentable.py</a>).
After waiting long enough, the hang turned out to be just an extremely slow
compilation.
This extreme slowdown turned out to be introduced somewhere between clang 3.4
and 3.5, and after bisecting I ended up at <a href="http://reviews.llvm.org/rL210828">http://reviews.llvm.org/rL210828</a>
("GVN: Enable value forwarding for calloc"). Timings of the test case on a
Xeon E5-2630 v3 @ 2.40GHz, with clang r210827:
7.98 real 7.86 user 0.12 sys
Same test case, with clang r210828:
215.30 real 207.70 user 7.59 sys
E.g., roughly a factor 27 slowdown!
It appears both targeting i386, -mdisable-fp-elim and -O2 are essential in the
command line for the test case:
clang -cc1 -triple i386 -mdisable-fp-elim -O2 -w glapi-long-compile.c
With regards to the test case itself, the 'meat' is a large generated function
_glapi_create_table_from_handle(), which basically consists of a very large
number of blocks like:
if(!disp->CallList) {
void ** procp = (void **) &disp->CallList;
snprintf(symboln, sizeof(symboln), "%sCallList", symbol_prefix);
*procp = dlsym(handle, symboln);
}
Strangely, though r210828 is apparently about calloc, the only calloc is at the
start of that function:
struct _glapi_table *
_glapi_create_table_from_handle(void *handle, const char *symbol_prefix) {
struct _glapi_table *disp = calloc(_glapi_get_dispatch_table_size(),
sizeof(_glapi_proc));
char symboln[512];
if(!disp)
return ((void *)0);
[...]</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>