This is the mail archive of the
mailing list for the GCC project.
Re: [LLVMdev] updated code size comparison
- From: James Courtier-Dutton <james dot dutton at gmail dot com>
- To: Bill Wendling <wendling at apple dot com>
- Cc: Paolo Bonzini <bonzini at gnu dot org>, John Regehr <regehr at cs dot utah dot edu>, gcc at gcc dot gnu dot org, llvmdev at cs dot uiuc dot edu
- Date: Mon, 7 May 2012 17:16:03 +0100
- Subject: Re: [LLVMdev] updated code size comparison
- References: <4B284431.email@example.com> <4B28A7B6.firstname.lastname@example.org> <7FF81310-08C3-4E17-9F6F-30643FADB110@apple.com>
On 17 December 2009 21:53, Bill Wendling <email@example.com> 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
>> 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.
> Perhaps just leaving out those volatile tescases which are miscompiled on other platforms, since not every volatile testcase fails for all compilers. :-)
Would it be possible for the test cases to detect if they have been
compiled wrongly, for example, check that volatile is actually
How about running the resulting compiled code is a small virtual
machine, that is configured to return a different value each time the
volatile variable is read. The test code could then read the volatile
variable twice and return a different result depending on whether the
two read values are different or not.
If the mis-compiled code only read the value once, having wrongly
optimized out the second read, the test would fail.