Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753022AbXFYHfr (ORCPT ); Mon, 25 Jun 2007 03:35:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750820AbXFYHfj (ORCPT ); Mon, 25 Jun 2007 03:35:39 -0400 Received: from mail-in-03.arcor-online.net ([151.189.21.43]:34422 "EHLO mail-in-03.arcor-online.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750755AbXFYHfj (ORCPT ); Mon, 25 Jun 2007 03:35:39 -0400 In-Reply-To: References: <467cac85.081b600a.5b88.457f@mx.google.com> <91b13c310706240558p70dbaed2g570b57ab480aa974@mail.gmail.com> <20070624222518.GA10398@flower.upol.cz> <1182723318.6819.5.camel@laptopd505.fenrus.org> <20070624232314.GA971@kvack.org> <1182730156.6819.8.camel@laptopd505.fenrus.org> <20070625001203.GB971@kvack.org> <1182731022.6819.10.camel@laptopd505.fenrus.org> <20070625004106.GA1094@stusta.de> <1182733127.6819.13.camel@laptopd505.fenrus.org> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Benjamin LaHaise , linux-kernel@vger.kernel.org, Arjan van de Ven , Adrian Bunk , Oleg Verych , rae l From: Segher Boessenkool Subject: Re: -Os versus -O2 Date: Mon, 25 Jun 2007 09:35:33 +0200 To: david@lang.hm X-Mailer: Apple Mail (2.623) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1388 Lines: 35 >> Also note that whether or not it is profitable to unroll >> a particular loop depends largely on how "hot" that loop >> is, and GCC doesn't know much about that if you don't feed >> it profiling information (it can guess a bit, sure, but it >> can guess wrong too). > > actually, what you are saying is that the compiler can't know enough > to figure out how to optimize for speed. it will just do what you tell > it to, either unroll loops or not. It bases its optimisation decisions on the options you give it, the profile feedback information you either or not gave it, and a whole bunch of heuristics. > this argues that both O2 and Os are incorrect for a project to use and > instead the project needs to make it's own decisions on this. For optimal performance, you need to fine-tune options yes, per file (or per function even!) > if this is the true feeling of the gcc team I'm very disappointed, it > feels like a huge step backwards. I speak only for myself. However this is the only way it _can_ be, the compiler isn't clairvoyant. Some of the heuristics sure could use some tuning, but they stay heuristics. Segher - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/