Re: Optimization advice for maintainers: go for low-hanging fruit

[Martin Buchholz <martin@xemacs.org>]

>>>>> "J" == Joe Buck <jbuck@synopsys.com> 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)