[LLVMdev] Phronix does another speed test

Duncan Sands baldrick at free.fr
Tue Nov 9 05:46:45 PST 2010


Hi Edwin,

>> http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1
>> as of version 2.8, LLVM is generating slower code than the newer GCCs
>> but generates the code more quickly.
>>
>
> I would be more concerned about the 'unable to compile', or 'compiled
> code not working correctly' issues. It would help if they filed bugs.

I analysed the dragonegg compile failures.  The graphicsmagick,
imagemagick, lame and x264 failures were all failures to link,
due undefined references to builtin_lfoor and/or builtin_lceil.
Recent gcc turns calls to floor/ceil followed by a cast to long
or long long into a call to an lfloor/lceil builtin.  These were
not being recognised by dragonegg, so were just being passed on
as is, resulting in the link failures.  I just added support for
these builtins and now all of the above programs compile on x86-64
linux.

All of the remaining failures (crafty, libgcrypt11 and openssl) were
due to using FD_ZERO which on some linux systems like mine uses a rather
bogus inline asm which dragonegg rejects:
   error: unsupported inline asm: input constraint with a matching output 
constraint of incompatible type!
The reason that this is not seen with llvm-gcc is that llvm-gcc uses
a fix-includes to correct the definition of FD_ZERO.  Adding support for
this kind of funky asm is PR3373.  It was done already in clang, but not
yet in llvm-gcc or dragonegg.

Ciao,

Duncan.



More information about the llvm-dev mailing list