From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25232 invoked by alias); 9 Apr 2008 06:49:52 -0000 Received: (qmail 25224 invoked by uid 22791); 9 Apr 2008 06:49:51 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out04.alice-dsl.net (HELO smtp-out04.alice-dsl.net) (88.44.63.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Apr 2008 06:49:32 +0000 Received: from out.alice-dsl.de ([192.168.125.60]) by smtp-out04.alice-dsl.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 08:42:40 +0200 Received: from basil.firstfloor.org ([78.53.157.189]) by out.alice-dsl.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Apr 2008 08:42:39 +0200 Received: by basil.firstfloor.org (Postfix, from userid 1000) id 6F0EC1B451F; Wed, 9 Apr 2008 08:49:23 +0200 (CEST) To: Mark Mitchell Cc: Jan Hubicka , Jan Hubicka , Richard Guenther , gcc-patches@gcc.gnu.org Subject: Re: Patch ping... From: Andi Kleen References: <20080405162606.GA22594@atrey.karlin.mff.cuni.cz> <84fc9c000804050953o429fde26jb3938827ff9dc5a@mail.gmail.com> <20080405195910.GF28471@atrey.karlin.mff.cuni.cz> <47FBCEF5.50001@codesourcery.com> <20080408223049.GJ16935@kam.mff.cuni.cz> <47FBF6FA.70305@codesourcery.com> Date: Wed, 09 Apr 2008 07:19:00 -0000 In-Reply-To: <47FBF6FA.70305@codesourcery.com> (Mark Mitchell's message of "Tue, 08 Apr 2008 15:51:38 -0700") Message-ID: <87tzibo74c.fsf@basil.nowhere.org> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-04/txt/msg00758.txt.bz2 Mark Mitchell writes: > Jan Hubicka wrote: > >> What I think -Os can be really useful for is well maintained code base, >> with code size constraints. (Linux kernel) You compile it with -Os and >> get small code except for the case you explicitly use __attribute__ >> ((hot)). Given the observation that just tiny portion of program is >> hot, it in general makes more sense than using -O2/-O3 and cold attribute. > > That makes sense, but it's only one usage model. Another case is > where you want your applications to be small -- perhaps because the > whole application is "cold". I'm running on an embedded device, I > want to have this application available, but flash is scarce, and I > expect to need this application only very rarely; please use no more > space than possible. But even such an embedded application might have a single function or two which is time critical. So giving a runtime switch for hot would even make sense for them. And if they don't want it, just should just not use __attribute__((hot)) Also there is plenty of precendence on other compilers for pragmas to change optimization levels on the fly inside files (I sometimes would really love that for -funroll-loops for example), so there seems to be definitely user demand for things like this. Also to be honest I would like to have a -Omostly-small That is current -Os is usually better for icache constrained applications that don't loop much (like a kernel), but sometimes it generates extremly bad code just to save a few bytes which has hurt in the past (as in appearing on profiles for macro benchmarks). One example for this is division code generation where on x86 -Os prefers always the hardware DIV instructions even when they can be magnitudes slower than an only slightly bigger expanded sequence. __attribute__((hot)) of course is the first step to fix that. -Andi