This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Compiler Analysis: 3.3, 3.4, or tree-ssa?
- From: Scott Robert Ladd <coyote at coyotegulch dot com>
- To: tm_gccmail at kloo dot net
- Cc: Matt Fago <fago at caltech dot edu>, gcc at gcc dot gnu dot org
- Date: Mon, 20 Oct 2003 21:40:43 -0400
- Subject: Re: Compiler Analysis: 3.3, 3.4, or tree-ssa?
- References: <Pine.LNX.4.21.0310201354430.3871-100000@mail.kloo.net>
tm_gccmail@kloo.net wrote:
IMHO, it will be more efficient to determine the optimization problem in
the compiler and fix it, instead of requiring everyone to waste CPU cycles
by running a genetic optimizer.
Agreed. I'm looking at this as a general testing and optimization tool
for *applications*, at the same level of development as unit testing and
profiling.
That Acovea may also useful in making GCC a better compiler is
serendipitous.
This isn't meant to denigrate your optimizer; it's merely to point out
that it's most useful as a compiler development tool to identify
optimization problems rather than as a end-user optimization tool.
The genetic algorithm is entirely impractical as a component of the
compiler, and I don't intend it as such.
The original concept grew out of my published benchmarks; people kept
telling me to use such-and-such options that often did little or nothing
to improve performance. I wanted to *know* which options generated the
fastest code. Acovea gives me that knowledge.
As the genetic algorithm evolved over the last year, I've found it
useful in other ways -- such as in verifying the interactions of
optimization algorithms. Algorithms may not necessarily be broken just
because they pessimize code, and certain optimizations may conflict in
combination; GCCis, after all, a complex system (in the mathematical sense).
The problem is that you're using this tool to identify the problem, then
avoid it. What we should be doing with it is to identify the problem and
fix it.
No, I'm using the tool to find the best set of optimizations for a given
performance-critical section of code. My framework identifies
pessimistic options for a given piece of code, and produces option sets
that produce substantially faster code than any -On option.
Yes, this may be because of a bug in GCC -- or, it could simply be
because a given piece of code is well-suited to a select group of
optimization algorithms.
Another note: This tool is not designed just for gcc; it works with any
language or compiler. While it certainly can find bugs and problems in a
specific compiler -- like GCC -- it is designed for other purposes as
well. For example, a GA can be quite illuminating in selecting
variations on algorithms, buffer sizes, inline limits -- the list goes
on and on.
If you can send me the source code and the resultant assembly code for the
"slow" and "fast" compiler options, I will take a look at it.
I'm doing this on my own time as quickly as I can. The test cases and
framework are finished and tested; I'll spend tomorrow polishing my
paper on the topic, and people can then decide how it fits with their
own goals.
--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing