From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5751 invoked by alias); 17 Aug 2009 07:19:39 -0000 Received: (qmail 5734 invoked by uid 22791); 17 Aug 2009 07:19:37 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_05 X-Spam-Check-By: sourceware.org Received: from smtp3.ugent.be (HELO smtp3.UGent.be) (157.193.49.127) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 17 Aug 2009 07:19:29 +0000 Received: from localhost (mcheck2.ugent.be [157.193.49.249]) by smtp3.UGent.be (Postfix) with ESMTP id ADFC2147669; Mon, 17 Aug 2009 09:19:25 +0200 (CEST) Received: from smtp3.UGent.be ([157.193.49.127]) by localhost (mcheck2.ugent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id gnLK-5r1qNk8; Mon, 17 Aug 2009 09:19:24 +0200 (CEST) Received: from mail.elis.ugent.be (mail.elis.UGent.be [157.193.206.48]) by smtp3.UGent.be (Postfix) with ESMTP id D59F0147670; Mon, 17 Aug 2009 09:19:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.elis.ugent.be (Postfix) with ESMTP id 61CBE918F18; Mon, 17 Aug 2009 09:19:23 +0200 (CEST) Received: from mail.elis.ugent.be ([127.0.0.1]) by localhost (mail.elis.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2s4zBTNxENz; Mon, 17 Aug 2009 09:19:20 +0200 (CEST) Received: from konijn.elis.UGent.be (konijn.elis.UGent.be [157.193.206.80]) by mail.elis.ugent.be (Postfix) with ESMTP id 4F673918F19; Mon, 17 Aug 2009 09:19:20 +0200 (CEST) Cc: ami_stuff , gcc@gcc.gnu.org Message-Id: From: Kenneth Hoste To: Martin Guy In-Reply-To: <56d259a00908160902q54cda0a6nab0d7eb28abd8d48@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: GCC 4..4.x speed regression - help? Date: Mon, 17 Aug 2009 08:53:00 -0000 References: <2fdfa587.3e8d2013.4a87ec55.d57bd@o2.pl> <74af2d11.6acc4366.4a8812b9.bdfcd@o2.pl> <56d259a00908160902q54cda0a6nab0d7eb28abd8d48@mail.gmail.com> X-j-chkmail-Enveloppe: 4A89047B.001/157.193.206.48/mail.elis.UGent.be/mail.elis.ugent.be/ X-j-chkmail-Score: MSGID : 4A89047B.001 on smtp3.UGent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham 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-08/txt/msg00279.txt.bz2 On Aug 16, 2009, at 18:02 , Martin Guy wrote: > Yes, GCC is bigger and slower and for several architectures generates > bigger, slower code with every release, though saying so won't make > you very popular on this list! :) > > One theory is that there are now so many different optimization passes > (and, worse, clever case-specific hacks hidden in the backends) that > the interaction between the lot of them is now chaotic. Selecting > optimization flags by hand is no longer humanly possible. That, and the fact that GCC supports so many (quite different) targets while keeping the set of optimization passes roughly equal across these targets probably also doesn't help... I'm aware there are (good) reasons to try and keep it that way, but it seems the reasons against it are getting stronger. Just my 2 cents. Kenneth PS: There's MILEPOST, but there are other projects too. Check out Acovea (http://www.coyotegulch.com/products/acovea) and my very own pet COLE (http://users.elis.ugent.be/~kehoste/, see the publications section). -- Kenneth Hoste Paris research group - ELIS - Ghent University, Belgium email: kenneth.hoste@elis.ugent.be website: http://www.elis.ugent.be/~kehoste blog: http://boegel.kejo.be