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
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 > > - added the x86 Open64 compilerI 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? -Eli
On 01/20/2010 05:54 PM, John Regehr 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 > > - added the x86 Open64 compiler >Hi, Could you also add a main() for each of these files, and do a very simple test that the optimized functions actually work? At least for functions that take only integers and return integers this could be automated if you compare -O0 output with the optimized outputs. The neon_helper.c testcase is clearly misoptimized by gcc-head here: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/compare_clang-head_gcc-head/compare_23BD1620_disasm.shtml Try calling it like this: int main() { printf("%d\n", helper_neon_rshl_s8(0x12345, 15)); return 0; } Prints 74496 here, and not 0 (gcc-head optimized it to a function returning 0). Best regards, --Edwin
> 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 you already know it) which is that real C code does just about anything that can be parsed :). If LLVM warns about this incorrect definition I can eliminate this kind of test case, I'll look into this as well. John
Hi Torok-> Could you also add a main() for each of these files, and do > a very simple test that the optimized functions actually work?Unfortunately, testing isolated C functions is much harder than just passing them random data! Consider this function: int foo (int x, int y) { return x+y; } The behavior of foo() is undefined when x+y overflows. If course it is trivial to come up with similar examples based on shifts, multiplies and divides, etc. A potential solution is "under-constrained execution": http://www.stanford.edu/~engler/issta07v-engler.pdf I will bug Dawson and Daniel and see if I can get ahold of some code for this. John