This is the mail archive of the
mailing list for the GCC project.
Re: Interesting paper from Perdue
- From: Vladimir Makarov <vmakarov at redhat dot com>
- To: tm_gccmail at kloo dot net
- Cc: Steven Bosscher <stevenb at suse dot de>, gcc at gcc dot gnu dot org
- Date: Tue, 21 Sep 2004 12:01:26 -0400
- Subject: Re: Interesting paper from Perdue
- References: <Pine.LNX.firstname.lastname@example.org>
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 other
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. 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.
...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.