similar to: [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

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/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

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

[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

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

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:

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

>> 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

> 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

> 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

> 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

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

>> 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

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, >

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?

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

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

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

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 >>> >>>