Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] detailed comparison of generated code size for LLVM and other compilers"
2009 Dec 14
0
[LLVMdev] detailed comparison of generated code size for LLVM and other compilers
On Dec 14, 2009, at 7:33 AM, John Regehr wrote:
> See here:
>
> http://embed.cs.utah.edu/embarrassing/
>
> There is a lot of data there. Please excuse bugs and other problems.
> Feedback would be appreciated.
Hi John,
I agree with the gcc folks: it's really important to get frame pointer
emission etc aligned across the various compilers. ICC defaulting to
frame
2009 Dec 14
2
[LLVMdev] detailed comparison of generated code size for LLVM and other compilers
On Dec 14, 2009, at 9:46 AMPST, Chris Lattner wrote:
>
> On Dec 14, 2009, at 7:33 AM, John Regehr wrote:
>
>> See here:
>>
>> http://embed.cs.utah.edu/embarrassing/
>>
>> There is a lot of data there. Please excuse bugs and other problems.
>> Feedback would be appreciated.
>
> Hi John,
>
> I agree with the gcc folks: it's really
2009 Dec 14
2
[LLVMdev] detailed comparison of generated code size for LLVM and other compilers
2009/12/14 Chris Lattner <clattner at apple.com>:
> I'd recommend targeting (with both -march and -mtune) a simple and
> commonly available CPU type like "core2" or "pentium4". ICC should
> have both of these and gcc/llvm definitely do.
While I would say that, to be fair, the comparison should be made with
the same options (-O3 only or something of the
2010 Jan 20
5
[LLVMdev] updated code size comparison
Hi folks,
I've posted an updated code size comparison between LLVM, GCC, and
others here:
http://embed.cs.utah.edu/embarrassing/
New in this version:
- much larger collection of harvested functions: more than 360,000
- bug fixes and UI improvements
- added the x86 Open64 compiler
John
2009 Dec 16
3
[LLVMdev] updated code size comparison
[cross-posting to the GCC and LLVM lists]
I've updated the code size results here:
http://embed.cs.utah.edu/embarrassing/dec_09/
The changes for this run were:
- delete a number of testcases that contained use of uninitialized local
variables
- turn off frame pointer emission for all compilers
- ask all compilers to target x86 + SSE3
- ask all compilers to not emit stack protector
2009 Dec 14
0
[LLVMdev] detailed comparison of generated code size for LLVM and other compilers
On Mon, Dec 14, 2009 at 3:29 PM, Renato Golin <rengolin at systemcall.org> wrote:
> 2009/12/14 Chris Lattner <clattner at apple.com>:
>> I'd recommend targeting (with both -march and -mtune) a simple and
>> commonly available CPU type like "core2" or "pentium4". ICC should
>> have both of these and gcc/llvm definitely do.
>
> While I
2010 Jan 26
2
[LLVMdev] some llvm/clang missed optimizations
A few random observations:
1.
Clang could do better with large but boring switches like this:
http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/E8/E88C5111.shtml
Performance of clang's output will be fine but this is a major code size
lose.
2.
Destruction of stupid loops is incomplete, sometimes due to phase
ordering problems:
2009 Dec 16
0
[LLVMdev] updated code size comparison
On 12/16/2009 03:21 AM, John Regehr wrote:
> Hopefully the results are more fair and useful now. Again, feedback is
> appreciated.
I would also avoid testcases using volatile. Smaller code on these
testcases is often a sign of miscompilation rather than optimization.
For example,
http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/076389.c is
miscompiled on GCC 3.4 and SunCC
2010 Jan 27
2
[LLVMdev] some llvm/clang missed optimizations
>> Repetitive code with lots of bitwise operations is compiled by LLVM into
>> much larger code than the other compilers:
>>
>> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/ED/ED37DAF5.shtml
>> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/1F/1F4003C7.shtml
>>
>> Note that this is straight-line code, so LLVM's output will
2009 Dec 14
2
[LLVMdev] detailed comparison of generated code size for LLVM and other compilers
> You'll probably need to some digging to make sure the defaults are exactly
> comparable. Are SSE and/or MMX used? This affects floating point codegen
> quite a bit. Are the target CPUs the same?
Good point. Would "generic i686" be a reasonable choice? Does that even
mean anything these days?
Anyway-- I'd appreciate some guidance on what you folks would find
2010 Jan 27
2
[LLVMdev] some llvm/clang missed optimizations
> Umm, can you find one that isn't a popcount implementation?
Ok.
MMX psadbw instruction:
http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/CE/CE3DA132.shtml
Position of first set bit:
http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/1F/1F4003C7.shtml
Log2 floor:
http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/83/837A80E9.shtml
Pixel format
2010 Jan 20
3
[LLVMdev] updated code size comparison
> I started looking through the llvm-gcc vs. clang comparisons, and
> noticed that in
> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/A9/A9AB5AE7.c
> , size_t is declared incorrectly. Any idea how that might have
> happened?
Hi Eli,
Thanks for pointing this out, I'll look into this tonight.
However I can give you the quick generic answer right now (of course
2009 Jul 18
0
[LLVMdev] speed and code size issues
We have some results that are somewhat entertaining and that relate to the
size/speed discussion.
The basic idea is exhaustive generation of C functions where "exhaustive"
is qualified by some structural restrictions (depth of AST, node type,
etc.).
For one particular set of restrictions we ended up with about 7 million C
functions. We then compiled each of these functions with 7
2009 Dec 14
4
[LLVMdev] detailed comparison of generated code size for LLVM and other compilers
>> There are probably other differing defaults besides frame pointers. Stack
>> protectors, perhaps.
>
> Yes, that's another good example,
Ok-- I assume I should just add '-fno-stack-protector' to the llvm-gcc and
clang command lines? I had totally missed that something like this was
turned on by default.
I'll re-run everything with this change, with frame
2009 Dec 17
1
[LLVMdev] updated code size comparison
On Dec 16, 2009, at 1:26 AM, Paolo Bonzini wrote:
> On 12/16/2009 03:21 AM, John Regehr wrote:
>> Hopefully the results are more fair and useful now. Again, feedback is
>> appreciated.
>
> I would also avoid testcases using volatile. Smaller code on these
> testcases is often a sign of miscompilation rather than optimization.
> For example,
>
2009 Dec 14
0
[LLVMdev] detailed comparison of generated code size for LLVM and other compilers
On Dec 14, 2009, at 11:04 AM, Dale Johannesen wrote:
>>
>> I agree with the gcc folks: it's really important to get frame
>> pointer
>> emission etc aligned across the various compilers. ICC defaulting to
>> frame pointers off and GCC/llvm defaulting to them on will seriously
>> warp the numbers.
>
> Where did the gcc folks express this opinion?
2009 Dec 14
0
[LLVMdev] detailed comparison of generated code size for LLVM and other compilers
On Dec 14, 2009, at 1:49 PM, John Regehr wrote:
>> You'll probably need to some digging to make sure the defaults are
>> exactly
>> comparable. Are SSE and/or MMX used? This affects floating point
>> codegen
>> quite a bit. Are the target CPUs the same?
>
> Good point. Would "generic i686" be a reasonable choice? Does that
> even
2010 Jan 20
0
[LLVMdev] updated code size comparison
On Wed, Jan 20, 2010 at 7:54 AM, John Regehr <regehr at cs.utah.edu> wrote:
> Hi folks,
>
> I've posted an updated code size comparison between LLVM, GCC, and
> others here:
>
> http://embed.cs.utah.edu/embarrassing/
>
> New in this version:
>
> - much larger collection of harvested functions: more than 360,000
>
> - bug fixes and UI improvements
2009 Jul 17
9
[LLVMdev] speed and code size issues
So it would appear that llvm-gcc and clang are both slower than
gcc4 which is infamous for being slow at compiling code, and
yes this is with a release build/--enable-optimizations.
This seems to go against notes such as
http://clang.llvm.org/features.html#performance
which claim clang is signifcantly faster than gcc.
Below are some times and the larger object files when
compiling an i386
2010 Jan 27
0
[LLVMdev] some llvm/clang missed optimizations
On Tue, Jan 26, 2010 at 5:55 PM, John Regehr <regehr at cs.utah.edu> wrote:
>>> Repetitive code with lots of bitwise operations is compiled by LLVM into
>>> much larger code than the other compilers:
>>>
>>>
>>> http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/ED/ED37DAF5.shtml
>>>
>>>