Some 4.4 project musings

[Andrew MacLeod]

Diego Novillo wrote:
> On Fri, Feb 1, 2008 at 3:55 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
>
>   
>>  1 - Pass cleanup.  There have been rumblings about this, but I haven't
>>     
>
> Yes, this is an area that is in desperate need of TLC.  Your plan
> looks good to me.  We need to have a mechanism to determine whether a
> pass did something, we need to be able to have different pipelines for
> different architectures.
>
> Do you have anything specific in mind?  Create a branch?  Work
> directly on mainline?
>   

I think I'll create a branch since its not completely clear if the 
chosen information will be sufficient..  First convert all the passes to 
pass some info back in an organized way and then there will be some 
collecting/experimenting to do.  I'll do the trees first, but make sure 
it can be applied to RTL as well.

>   
>>  2 - Interface to the virtual operands. The virtual operand web provides
>>  what really amounts to low level detail of memory accesses. Every pass
>>
>>     
Richi's work will probably change what the web looks like, so this seems 
like a good item for me to defer for a bit until we see where we end up.
>>  3 - SRA.  There appear to be some deficiencies in SRA, and also how it
>>  interacts with the MEMSSA partitioner. I found when looking at some 4.3
>>
>>     
> Agreed.  SRA needs a new implementation.
>   

Richi's work may completely remove need for touching SRA, so I'm going 
to punt on this for the time being as well.
>   
>>  4 - SSA pressure reduction. I'm throwing this back on the table. I never
>>  quite got around to it before, and nothing has changed to resolve the
>>  issues. We freely create as much register pressure in the SSA optimizers
>>  as we want (as we should be able to).  The backend has doing nothing to
>>  address the issue and the RTL register allocator is simply swamped by
>>  the sheer quantity of live ranges sometimes.  Perhaps Vlad's RA will get
>>  in this release, and/or perhaps the need for this will be eliminated by
>>  something else, but it is something that may help code generation in the
>>  short term at least.
>>     
>
> What about the RTL expansion from SSA directly?  This is an area that
> is going to affect the tuples branch very soon.  We are currently
> going into RTL from tuples directly (no TER), but since most passes
> have not been converted, I can yet tell how much of a problem this is.
>  In a few weeks we'll hit this problem.
>
>   

Thats a lot more work, and by itself may actually increase pressure in 
the average case :-)  It will be interesting to see if anything has 
changed in the past few years regarding RTL that gets generated without 
TER. It would be nice if it wasn't needed, but I'm not aware of work 
which has changed enough to help select better RTL patterns. we'll see 
:-) It will be interesting to see what happens.  As an easy experiment, 
have you tried a straight comparison with -fno-tree-ter on SPEC or 
anything like that?  It may give you some idea of what to expect.

The pressure is likely to go up since TER usually moves defs closer to 
the use... I have no data whatsoever, but I would think  that TER 
reduces the pressure slightly in the average case. The larger 
pathological cases are a little more unpredictable.


Andrew