This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: detailed comparison of generated code size for GCC and other compilers
On 12/14/2009 09:31 PM, John Regehr wrote:
Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to
agree with both of your suggestions. I'll re-run everything w/o frame
pointers and ignoring testcases where some compiler warns about use of
uninitialized local. I hate the way these warnings are not totally
reliable, but realistically if GCC catches most cases (which it almost
certainly will) the ones that slip past won't be too much of a problem.
I also wonder if you have something like LTO enabled. This function
produces completely bogus code in LLVM, presumably because some kind of
LTO proves that CC1000SendReceiveP is never written. Of course, this
assumption would be wrong at runtime in a real program.
http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/015306.c
Of course the answer is not to disable LTO, but rather to add an
"initializer" function that does
volatile void *p;
memcpy (CC1000SendReceiveP__f, p, sizeof (CC1000SendReceiveP__f));
memcpy (CC1000SendReceiveP__count, p, sizeof (CC1000SendReceiveP__count));
memcpy (CC1000SendReceiveP__rxBuf, p, sizeof (CC1000SendReceiveP__rxBuf));
... and to make all variables non-static (otherwise the initializer
would have to be in the same file, but that would perturb your results).
I also agree with others that the frame pointer default is special
enough to warrant adding a special -f option to compilers that generate
it, if some other compilers do not generate it.
Paolo