Re: Interesting paper from Perdue

[Daniel Berlin <dberlin@dberlin.org>]

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