Some thoughts about steerring commitee work

[Vladimir N. Makarov]

Ian Lance Taylor wrote:

>
>These charts are certainly discouraging.  On the other hand, for some
>real code we're seeing each new version of gcc produce an incremental
>runtime improvement.  So I'm not sure what to make of it.
>
>This is hardly a new thought, but I believe that for the i386 gcc is
>handicapped by reload.  No matter how smart we are before reload, it
>just take one poor decision by reload in an inner loop and we've lost
>all the gains.  Reload has enormous complexities which are mostly
>irrelevant for the i386.  And I think that the idea of doing register
>allocation separately from spill code generation does not make sense
>on the i386.
>
>  
>
I would agree if we were talking about all gcc register allocation.  All 
gcc register allocation is really bad.  But there are different spills.  
Ones are because of the register pressure and another ones are because 
of the insn operand constraint combination.  The both can be taken into 
account before the reload in some acceptable way.

That is what impression I got from implementation of a register 
allocation without the reload for x86 and x86_64 and one with  the 
reload.  You can get the same improvement for x86.

As for x86_64 I found that spilling because register pressure is not so 
high right now (at least for x86_64 and for SPEC2000 because it has 
exactly in 2.5 more times more integer registers).  Therefore I 
mentioned about putting more values on the registers.  I hope LTO will 
help in that way too.
 
Reload is a mess but in local context it is doing a good job.  It was 
refined for many years and conceptually it is not so difficult to 
understand.  Removing it is not a rewarding job probably.  May be we 
need just to improve it and have a better documentation.

>I don't think gcc has hit any sort of wall, except insofar as we have
>no plan for eliminating reload.  I don't think portability comes into
>play here.
>
>That said, I certainly agree that we should try to figure out what is
>going on as much as possible.
>
>I also want to say that at present LTO is a collection of different
>projects.  Most of them are aimed directly at speeding up the
>compiler, reducing compile time.  So far nobody is working on any
>changes to the actual optimization framework.  So I'm not too
>concerned yet about LTO in this context.  I certainly agree that when
>LTO moves into an optimization phase, we need to make sure that any
>default passes pay off in terms of compilation time or runtime
>performance. 
>
>  
>
I am agree that LTO is the next big project which could help gcc in many 
way.  And we need to do this to keep gcc in pace with other compilers 
(mostly Intel).