<html>
<head>
<base href="http://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 --- - GCC4.9.2 optimizer produces 20% faster code than clang clang-600.0.56 (Xcode 6.1.1)"
href="http://llvm.org/bugs/show_bug.cgi?id=21760">21760</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>GCC4.9.2 optimizer produces 20% faster code than clang clang-600.0.56 (Xcode 6.1.1)
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>3.5
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Macintosh
</td>
</tr>
<tr>
<th>OS</th>
<td>MacOS X
</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>LLVM Codegen
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>david.hoerl@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=13439" name="attach_13439" title="Archive with source and two compiled apps">attachment 13439</a> <a href="attachment.cgi?id=13439&action=edit" title="Archive with source and two compiled apps">[details]</a></span>
Archive with source and two compiled apps
As an Apple developer, I got sucked into assisting the libjpeg-turbo project
with a few issues, and then involved myself in their <a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Performance disparity between clang/LLVM and GCC when using libjpeg-turbo"
href="show_bug.cgi?id=16035">bug 16035</a>. As I told DRC,
just pointing out that the overall performance was slower wasn't going to prod
any particular action by llvm, since there was no real specifics offered.
Because I sort of borked up 16035, I thought it wise to open up a new bug with
specific information and a small demo file that anyone there can use to test
with.
DRC is building his gcc code with version 4.2, and I tested with that binary.
Using -Ofast with the latest clang, the performance of the Huffman coder was as
stated - about 20% slower. The structure of the problematic code is in a
Huffman encoding section, where currently there are 63 replicated blocks of
code, as macros, each with a different "seed" integer. It also appears that for
a "common" jpeg image, foo == 0 is true eight times more than not, so it really
helps if the code efficiently handles the 'equals 0' case.
The current macro is structured as:
int x;
int foo;
if((foo = table[x])) {
r++;
} else {
// a bunch of code that acts on foo
}
What clang does is product assembler that mimics each block above. GCC, on the
other hand, creates an intermediate jump table, and produces assembler with the
first test inline followed by an optional jump:
if(!(foo = table[x])) {
jump A;
}
r++;
L_someLabel_A: // for A to return to
if(!(foo = table[x])) {
jump B;
}
r++;
L_someLabel_B: // for B to return to
Great! So I modified the macros to do the same (more or less) in C, using the
address of label C extension, so that I only needed one block of code to jump
to (the common block acts on "foo"). I compiled my modified app, and now clang
was executing the benchmark test with the same performance [new clang with new
code == gcc 4.2 with old code].
Then I wondered, how would a new version of gcc do with the old code or new
code? I used Homebrew to install gcc 4.9 (4.2 isn't even supported!), and
retested (building with -O3). Ugh! Using my modified code, gcc is again 20%
fast - perhaps even more [new code, new clang < new gcc].
Looking at the assembler (using the fantastic Hopper tool), you can see that
gcc has really squeezed that first test down:
GCC:
0000000100000aa9 movsx r9d, word [ds:rsi+0x30]
; XREF=_encode_one_blockX2+870
0000000100000aae lea r13, qword [ds:0x100000ac1]
0000000100000ab5 test r9d, r9d
0000000100000ab8 jne 0x1000007c0 ; NOTE JUMP ONLY TAKEN IF THE
VARIABLE != 0
0000000100000abe add ebp, 0x1
CLANG:
00000001000007de mov rcx, qword [ss:rbp+var_38]
; XREF=_encode_one_blockX2+143
00000001000007e2 mov cx, word [ds:rcx+0x4]
00000001000007e6 test cx, cx
00000001000007e9 je 0x1000007f7 ; JUMP IS USUALLY TAKEN
00000001000007eb lea r11, qword [ds:0x1000007fa]
00000001000007f2 jmp 0x100000cef
00000001000007f7 inc r15d
; XREF=_encode_one_blockX2+169
I've attached the following in an archive:
main.c (so you can build an real binary)
testMacro.c (cc -O3 main.c testMacro.c -o ...)
clang.out (set 'cc' to the latest clang in Xcode)
gcc.out (set 'cc' to gcc4-9)</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>