Re: Register Pressure in Instruction Level Parallelism

[Vladimir Makarov <vmakarov@redhat.com>]

Michael Kruse wrote:
>
>
> Vladimir Makarov wrote:
>> Michael Kruse wrote:
>>> If the register sufficiency is higher than the physical number of 
>>> registers, spill code is added to the graph.
>>>
>> For me, that is the most interesting part, unfortunately Touti (as I 
>> remember) in his thesis say practically nothing about this.
> In the thesis, a modified Poletto algorithm is presented to add spill 
> code.
>
>
I've just checked the thesis again.  I don't think decreasing register 
pressure through spilling will work well.  First of all Polleto linear 
scan RA is worse than Chaitin-Briggs approach.  Even its major 
improvement extending linear scan is worse than Chaitin-Briggs 
approach.  My experience with an ELS implementation in GCC has shown me 
this although in original article about ELS the opposite is stated (the 
comparison in the article was done in GCC but with the new ra project 
which was unsuccessful implementation of Chaitin-Briggs RA and it was 
done only on ppc64.  I am sure that on x86/x86_64 ELS would behave even 
worse).  That is about basic RA spill in Touti's thesis.

The bigger problem is that decreasing register pressure does not take 
live range splitting into account what good modern RAs do.  With this 
point of view, an approach for register pressure decrease in Bob 
Morgan's book is more perspective because it does also live range 
splitting (by the way, I tried Morgan's approach with the old RA more 
than 5 year ago and did not look compelling for me that time).
>>> I'd prefer to implement this for the gcc, but my advisor wants me to 
>>> do it for the university's own compiler. Therefore I could also need 
>>> arguments why to do it for the GCC.
>>>
>> Personally, I'd love to see this work done in GCC. I believe the 
>> research work in compiler field should be done in real industrial 
>> compilers because that is a final target of the research.  I saw many 
>> times that researchers report big improvements of their algorithms 
>> because they are using toy compilers but when the same algorithms are 
>> implemented in GCC they give practically nothing.  For me a toy 
>> compiler criteria is defined how good they are on some generally used 
>> compiler benchmarks as SPEC (the better existing compiler 
>> performance, the harder to get the same percent improvement).  So if 
>> your university compiler performance is close for example to 
>> SPECFP2000,  I think you could use it to get a real optimization impact.
>>
>> On the other hand, you definitely will get better numbers (and 
>> spending less time) using a toy compiler than GCC and your research 
>> probably could look more successful with the academic point of view.
> I don't think it a toy project. Industry is involved (embedded 
> systems) and it also has multiple back-ends. The problem with it is, 
> that it is (at least partially) proprietary. And I don't know about 
> the other part. However, you can't download it on the web.
Could you tell us what compiler is this?