On 17 December 2009 21:53, Bill Wendling wrote:
> 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. Small
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
Yes, that was my point. If you want to make a separate section for
volatile, that would indeed be helpful.
I checked and there are about 37,000 harvested functions containing the
volatile qualifier. Next time, there will be even more since we'll be
harvesting code from the FreeBSD kernel in
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 miscomp
On Thu, Dec 17, 2009 at 19:54, Eric Botcazou wrote:
>> However I would prefer to leave these testcases in, unless there is a
>> strong feeling that they are too distracting. They serve as poignant
>> little reminders about how easy it is to get volatile wrong...
>
> They skew the results in favor
> However I would prefer to leave these testcases in, unless there is a
> strong feeling that they are too distracting. They serve as poignant
> little reminders about how easy it is to get volatile wrong...
They skew the results in favor of the less careful compilers so they are more
than simpl
Hi Paolo,
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 5.10.
Yeah, there are defin
Moreover, aggregating those boolean results to yield things like "X
generated larger code than Y NN% of the time" seems even weirder.
Is this really useful information, other than for marketing?
Hi Miles-
Did you click through to one of the pages that shows a rank-ordered list
of functions wh
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.
John Regehr writes:
> I've updated the code size results here:
>
> http://embed.cs.utah.edu/embarrassing/dec_09/
The thing that bothers me about this is that you seem to put a lot of
emphasis on the test "X generated larger code than Y" without any
reflection of how much larger (it could be 1 b
[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 compil
11 matches
Mail list logo
