Compiler Analysis: 3.3, 3.4, or tree-ssa?

[Scott Robert Ladd]

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