Re: updated code size comparison

2009-12-17 Thread John Regehr
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

Re: updated code size comparison

2009-12-17 Thread Paolo Bonzini
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

Re: updated code size comparison

2009-12-17 Thread Eric Botcazou
> 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

Re: updated code size comparison

2009-12-17 Thread John Regehr
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

Re: updated code size comparison

2009-12-16 Thread John Regehr
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

Re: updated code size comparison

2009-12-16 Thread Paolo Bonzini
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.

Re: updated code size comparison

2009-12-15 Thread Miles Bader
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