From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6474 invoked by alias); 19 Jan 2004 00:53:28 -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 6251 invoked from network); 19 Jan 2004 00:53:27 -0000 Received: from unknown (HELO yosemite.airs.com) (209.128.65.135) by sources.redhat.com with SMTP; 19 Jan 2004 00:53:27 -0000 Received: (qmail 21622 invoked by uid 10); 19 Jan 2004 00:53:27 -0000 Received: (qmail 23639 invoked by uid 500); 19 Jan 2004 00:53:18 -0000 From: Ian Lance Taylor To: "Zack Weinberg" Cc: gcc@gcc.gnu.org Subject: Re: Can we speed up the gcc_target structure? References: <20040118083738.10772.qmail@gossamer.airs.com> <87smid8w9q.fsf@codesourcery.com> <87ad4ksxma.fsf@egil.codesourcery.com> Date: Mon, 19 Jan 2004 00:53:00 -0000 In-Reply-To: <87ad4ksxma.fsf@egil.codesourcery.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-01/txt/msg01227.txt.bz2 "Zack Weinberg" writes: > Of course inefficiencies are going to be introduced if we just convert > each macro to a target hook with the same semantics. But that isn't > the only option on the table. The right thing is to redesign this > interface so that it doesn't *need* 100+ macros and toggles. If this > is done properly, then not only should there be no inefficiency > introduced by going through the target vector, but also we would have > something that was straightforward to maintain and straightforward to > add support for new architectures. > > As a data point, I am aware of another (proprietary) compiler that > completely isolates the back end from the optimizers, to the point > where the back end module can be swapped out at runtime, and it > benchmarks competitively or faster than GCC on similar input. So I > don't believe that this is impossible. Sounds good. I think most people would agree that gcc has always brought details of the target too far forward in the compilation process. But it's a pretty substantial project, given the current code base. Ian