This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Interesting paper from Perdue



On Sep 21, 2004, at 12:01 PM, Vladimir Makarov wrote:


tm_gccmail@kloo.net wrote:

On Mon, 20 Sep 2004, Steven Bosscher wrote:


I don't know if anyone has ever seen/read/mentioned this paper
before, I might have missed it. Otherwise, interesting reading:
https://engineering.purdue.edu/ECE/Research/TR/2004pdfs/TR-ECE-04 -01.pdf


Gr.
Steven


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 other
optimization passes.



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.

...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.


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.


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.


Vlad





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]