From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5088 invoked by alias); 18 Jan 2004 09:03:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5079 invoked from network); 18 Jan 2004 09:03:13 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sources.redhat.com with SMTP; 18 Jan 2004 09:03:13 -0000 Received: (qmail 20314 invoked from network); 18 Jan 2004 09:03:07 -0000 Received: from taltos.codesourcery.com (zack@66.92.218.83) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 18 Jan 2004 09:03:07 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Sun, 18 Jan 2004 01:02:25 -0800 From: "Zack Weinberg" To: Ian Lance Taylor Cc: gcc@gcc.gnu.org Subject: Re: Can we speed up the gcc_target structure? References: <20040118083738.10772.qmail@gossamer.airs.com> Date: Sun, 18 Jan 2004 09:03:00 -0000 In-Reply-To: <20040118083738.10772.qmail@gossamer.airs.com> (Ian Lance Taylor's message of "18 Jan 2004 03:37:38 -0500") Message-ID: <87smid8w9q.fsf@codesourcery.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-01/txt/msg01156.txt.bz2 Ian Lance Taylor writes: > Back in the old days, gcc had a lot of code which was conditionally > compiled with #ifdef. That was ugly, but the resulting code was fast. > Over time, a lot of the parameters checked with #ifdef were converted > into macros which were checked at runtime using if. That was less > ugly, and, since the macros normally had constant values, when gcc was > compiled with an optimizing compiler, the code was just as fast in the > normal case. When it was slower, it was generally because the > compiler was doing something it couldn't do before. [...] Any change along these lines loses what I think is a critical property of the target vector, which is that modifications to the target-specific code on the far side of it do *not* require recompilation of the entire machine-independent compiler. I consider it a desirable and achievable goal to be able to swap out the entire back end without rebuilding any of the optimizers; this entails having *everything* go through the target vector or some other sort of link-time interface. (For instance, I see no need to change the way recog.c interacts with insn-recog.c for this purpose.) Furthermore, while a 3% measured speed hit is a concern, I think that trying to win it back by undoing the targetm transformation - in the object files, if not in the source code - is barking up the wrong tree. Instead we should be looking for ways to avoid having targetm hooks in critical paths in the first place. It's been my experience that that is a much more fruitful source of optimization opportunities. zw