Interesting paper from Perdue
Daniel Berlin
dberlin@dberlin.org
Tue Sep 21 18:39:00 GMT 2004
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
>
>
More information about the Gcc
mailing list