Re: Register Pressure in Instruction Level Parallelism

[Michael Kruse <meinert at uni-paderborn dot de>]

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.

> > So, now my questions: How much do you think could this could improve 
> > compiled code speed? Would the current GCC/YARA benefit from such an 
> > optimization pass at all?
> I think nobody can answer the questions until it is implemented.
My main intention to ask this is that somebody might have said, that it 
was not worth the effort. Therefore, I could have saved me a lot of work.

> If you are going to work on this project, some small advice about 
> evaluating register sufficiency.  I found that register pressure is 
> already practically minimized before insn-scheduling (I suspect that 
> it is mostly done in TER).  By the way, it also means that tree 
> balancing (which is actually much more complicated issue because it is 
> not tree but DAG) is not necessary for the backend as it was done in 
> Preston Briggs project (and mentioned in proposed Ken Zadeck's pass 
> stack).
Thank you. I am grateful for any advice.
> > What are the chances that this could get into the main GCC tree if it 
> > shows up to be an improvement?
> I don't see any problem to get the code into main GCC tree if you get 
> even 1-2% improvement.  Although there are some technical questions 
> (like code fitting into gcc practice standards) and  commitment to 
> maintain the code.  But this problems could be definitely overcome.
I'd be willing to do this.
> > 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.

Regards,
Michael Kruse

--
Tardyzentrismus verboten!

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature