From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1950 invoked by alias); 24 Dec 2002 07:30:07 -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 1897 invoked from network); 24 Dec 2002 07:30:01 -0000 Received: from unknown (HELO pimout1-ext.prodigy.net) (207.115.63.77) by 209.249.29.67 with SMTP; 24 Dec 2002 07:30:01 -0000 Received: from wobble.local (adsl-64-173-27-66.dsl.sntc01.pacbell.net [64.173.27.66]) by pimout1-ext.prodigy.net (8.12.3 da nor stuldap/8.12.3) with ESMTP id gBO7TmMm148440; Tue, 24 Dec 2002 02:29:49 -0500 Received: (from martin@localhost) by wobble.local (8.11.6/8.11.6) id gBO7TmB13390; Mon, 23 Dec 2002 23:29:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15880.3308.59512.557503@wobble.local> Date: Tue, 24 Dec 2002 06:34:00 -0000 From: Martin Buchholz To: Joe Buck Cc: gcc@gcc.gnu.org Subject: Re: Optimization advice for maintainers: go for low-hanging fruit In-Reply-To: <20021223155357.B3289@synopsys.com> References: <15874.46305.491247.297301@wobble.local> <20021223155357.B3289@synopsys.com> Reply-To: martin@xemacs.org X-SW-Source: 2002-12/txt/msg01400.txt.bz2 >>>>> "J" == Joe Buck writes: >> c++/8936: Declaration of never defined member function changes generated code >> optimization/8952: failure to optimize away trivial C++ object creation >> optimization/8967: Making class data members `const' pessimizes code >> optimization/9016: Failure to consistently constant fold "constant" C++ objects J> Some of the oddities you point out seem to come from the fact that J> subsequent passes of the compiler seem to succeed in doing optimizations J> only sometimes, and that conditions for these passes to work (e.g. dead J> store elimination) are rather brittle. It would certainly be interesting J> to determine just what is different in cases 8936 and 8967. Some of those bugs are regressions from previous g++ versions, showing that g++ can certainly do a better job without massive infrastructure work. For example, Wolfgang's experiments with PR8967 shows things getting worse with successive g++ versions. J> Many of us believe that tree-based optimizations can be the way out for J> many of these cases: do optimizations that are easy on trees well before J> conversion to RTL. Work is in progress to provide an infrastructure J> that will allow this to be done. Another argument for why I expect g++ to do better today: A clever C++ compiler can figure out that an expression like Complex(1,2) is a compile-time constant and optimize appropriately at compile-time. But semantically, this is equivalent to double real = 1.0; double imag = 2.0; which a C compiler can do constant-folding on, probably just as well as C++. >From a very high level, I regard a C++ front end's job as translating C++ into something semantically very close to C code. Although there may be additional opportunities for optimization by understanding and optimizing C++ constructs, the meat of the optimizations should be occuring at the "C level". For example, if a C++ compiler sees Complex(1,a) + Complex(2,b) it shouldn't say "no constants here, so no constant-folding here." Instead, there should be constant-folding on the real parts of those Complex variables, just as if it had been written in C using variables of type "double". So I'm still a believer in the value of low-level optimizations, ones that don't know about higher-level things like classes. Martin (not a compiler writer)