This is the mail archive of the
mailing list for the GCC project.
Re: Interesting paper from Perdue
On Sep 21, 2004, at 12:01 PM, Vladimir Makarov wrote:
On Mon, 20 Sep 2004, Steven Bosscher wrote:I think the approach mentioned in article has a merit for any
compiler. Any optimized compiler is bunch of pass because of
complexity task. Many passes are trying to solve subproblem not taking
other passes into account. It creates unpredictable compiler
behaviour for given program when an optimization is on or off.
I don't know if anyone has ever seen/read/mentioned this paper
before, I might have missed it. Otherwise, interesting reading:
I'll digress and rant a bit; apologizes in advance.
This is just the tip of the iceberg, really. There are many other
instances where various optimizations are improved in isolation and
degrade performance because they don't consider the effects on the
I agree with this. Gcc probably is a compiler with very upredictabe
behaviour because inadequate register allocator/scheduler. But
writing a good register allocator is not easy task in gcc because of
very rich register file model and a lot of machine-dependent macros
used by gcc ports.
...and the register allocator doesn't handle the increased register
pressure well, so the net result is very little improvement.
We really spend some time improving the foundation of GCC instead of
piling more and more optimizations on top of it.
We have a register file model so rich that no single architecture is
described well enough to get good results.
There is something ironic about this.
The colour-based register allocator project is an example of this. I
know about this because I worked on register allocator improvements
and I am still working on it. I think the key component is reload
pass. Tasks solved by reload should be combined with the register
allocator. We should rid off reload. But it is an eneormous task.
Yes, which is one of a myriad of reasons new-ra never succeeded.
The goals were too ambitious
Getting rid of reload is a project all itself.