search for: jan_10

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: http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/FC/FCADC848.shtml Sometimes...

>> 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 run 4-5 >> times longer than everyone else's. >> >> I'll be interested...

> 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 conversion: http://embed.cs.utah.edu/embarrassing/ja...

On Tue, Jan 26, 2010 at 12:36 PM, John Regehr <regehr at cs.utah.edu> wrote: > 2. > Sometimes not: > > http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/EC/ECC74C0C.shtml The primary issue here is that scalar evolution doesn't know how to deal with loops using "sle" for the exit condition. Shouldn't be too hard to fix now that we have overflow flags for addition. > 3. > > Repetitive code with lots of bit...

...n 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 >>> >>> 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 run 4-5 >>> times longer than everyone else's. >>>...

On Tue, Jan 26, 2010 at 7:42 PM, John Regehr <regehr at cs.utah.edu> wrote: >> 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 conversi...

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

...in this version: > > - much larger collection of harvested functions: more than 360,000 > > - bug fixes and UI improvements > > - added the x86 Open64 compiler 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? -Eli

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

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

On Wed, Jan 20, 2010 at 12:05 PM, John Regehr <regehr at cs.utah.edu> wrote: >> 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 >...