From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19154 invoked by alias); 13 May 2009 07:33:33 -0000 Received: (qmail 19145 invoked by uid 22791); 13 May 2009 07:33:32 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 13 May 2009 07:33:27 +0000 Received: from basil.firstfloor.org (p5B3CB273.dip0.t-ipconnect.de [91.60.178.115]) by one.firstfloor.org (Postfix) with ESMTP id E3E431AB0002; Wed, 13 May 2009 09:38:43 +0200 (CEST) Received: by basil.firstfloor.org (Postfix, from userid 1000) id D8AC31D0286; Wed, 13 May 2009 09:33:20 +0200 (CEST) To: "Joseph S. Myers" Cc: Chris Lattner , Vladimir Makarov , "gcc.gcc.gnu.org" , Evan Cheng Subject: Re: New GCC releases comparison and comparison of GCC4.4 and LLVM2.5 on SPEC2000 From: Andi Kleen References: <4A098018.1030900@redhat.com> Date: Wed, 13 May 2009 08:44:00 -0000 In-Reply-To: (Joseph S. Myers's message of "Tue, 12 May 2009 18:05:34 +0000 (UTC)") Message-ID: <87d4admp8f.fsf@basil.nowhere.org> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-05/txt/msg00331.txt.bz2 "Joseph S. Myers" writes: > On Tue, 12 May 2009, Chris Lattner wrote: > >> 1. I have a hard time understanding the code size numbers. Does 10% mean that >> GCC is generating 10% bigger or 10% smaller code than llvm? > > I have a different comment on the code size numbers: could we have > comparisons of code size for -Os rather than (or in addition to) -O2 and > -O3? If someone is particularly concerned with code size, -Os is what > they are expected to use. It's a slippery slope that -O2 is getting so bad regarding code size. What should people do who need performance, but cannot completely disregard code size (and can't use profile feedback for some reason). Also with limited caches code size for large programs typically tends to affect performance too. In my experience -Os has some significant drawbacks because it prioritizes everything code size over everything else. For example one -Os problem case we ran into was on x86 it always uses a fully generic hardware division when dividing by constant even for cases where you can generate a much faster sequence by spending a few more bytes. Also it disables a lot of other useful optimizations. -Andi -- ak@linux.intel.com -- Speaking for myself only.