[LLVMdev] Phronix does another speed test

[Samuel Crow]

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.

_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Evan Cheng]

There has not been much analysis apart from John-the-ripper issue (it's a scheduler deficiency). It would be nice if people can analyze the individual tests and file detailed bugs.

Evan

[Duncan Sands]

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.

[Török Edwin]

On Mon, 8 Nov 2010 15:42:33 -0800 (PST)
Samuel Crow <samura...@yahoo.com> wrote:

> 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 don't know what is wrong with the BYTE benchmark for example, I
thought its part of the LLVM test suite.

Best regards,
--Edwin

[Dale Johannesen]

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

It is claimed that the Byte Unix benchmarks compile with llvm-gcc but do not work. They built and worked fine for me with TOT on Darwin X86-64. (I could not find version 3.6; 3.11 is in common use, and has been since at least 2003. There are some comments in the code that call it 3.6, however, and others [dated 1991] that call it 3.9, so I think we're talking about the same thing. But maybe not.)

It's also claimed they don't build with Clang. This is true:

./src/hanoi.c:65:3: error: non-void function 'mov' should return a value
[-Wreturn-type]
return;
^
The function in question is logically void but is declared without a return type (thus implicit int), a style that was common pre-C89 but is now rare. It's clearly legal in both C89 and C99, but last time this came up there was sentiment that rejecting it anyway was the best thing for users. Whatever you think of that, it means we can't build this benchmark.

[Dale Johannesen]

Now that I've hunted a little harder in the Phoronix site, I see they do have a downloadable copy of the benchmarks:
http://www.phoronix-test-suite.com/index.php?k=downloads

Their harness, unfortunately, is GPL3, which means I can't use it.

On Nov 9, 2010, at 1:39 PMPST, Dale Johannesen wrote:

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