From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28573 invoked by alias); 15 Dec 2009 08:44:50 -0000 Received: (qmail 28559 invoked by uid 22791); 15 Dec 2009 08:44:50 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Dec 2009 08:44:46 +0000 Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id AF1C67D02535; Tue, 15 Dec 2009 00:44:44 -0800 (PST) Received: from [17.116.206.166] (Unknown_Domain [17.116.206.166]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 5F.36.04097.C7C472B4; Tue, 15 Dec 2009 00:44:44 -0800 (PST) Subject: Re: detailed comparison of generated code size for GCC and other compilers Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Chris Lattner In-Reply-To: Date: Tue, 15 Dec 2009 08:44:00 -0000 Cc: gcc@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <58B40990-E6F2-46EF-8079-8232DC1CA7C1@apple.com> References: <4B265B23.1010102@cs.utah.edu> <87hbrty1k5.fsf@basil.nowhere.org> <20091214171745.GD16474@basil.fritz.box> To: Paolo Bonzini X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-12/txt/msg00205.txt.bz2 On Dec 15, 2009, at 12:28 AM, Paolo Bonzini wrote: > 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. >=20 > I also wonder if you have something like LTO enabled. No, he doesn't enable LLVM LTO. Even if it did, LTO wouldn't touch the 'CC= 1000SendReceiveP*' definitions because they are not static (unless he expli= citly built with an export map). I haven't analyzed what is going on in this example though. The code is pr= obably using some undefined behavior and getting zapped. -Chris > This function produces completely bogus code in LLVM, presumably because= some kind of LTO proves that CC1000SendReceiveP is never written. Of cour= se, this assumption would be wrong at runtime in a real program. >=20 > http://embed.cs.utah.edu/embarrassing/src_harvested_dec_09/015306.c >=20 > Of course the answer is not to disable LTO, but rather to add an "initial= izer" function that does >=20 > volatile void *p; > memcpy (CC1000SendReceiveP__f, p, sizeof (CC1000SendReceiveP__f)); > memcpy (CC1000SendReceiveP__count, p, sizeof (CC1000SendReceiveP__count)); > memcpy (CC1000SendReceiveP__rxBuf, p, sizeof (CC1000SendReceiveP__rxBuf)); >=20 > ... and to make all variables non-static (otherwise the initializer would= have to be in the same file, but that would perturb your results). >=20 > 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 so= me other compilers do not generate it. >=20 > Paolo >=20