[ast-optimizer-branch]: SSA-CCP on tree-ssa

Daniel Berlin dan@cgsoftware.com
Thu Dec 6 10:45:00 GMT 2001


On Thursday, December 6, 2001, at 12:33  PM, Diego Novillo wrote:

> On Fri, 19 Oct 2001, Daniel Berlin wrote:
>
>> Rewrites ssa-ccp so it doesn't depend on an intermediate
>> representation, by abstracting what it really wants to do into
>> function pointers.
>>
> While I like the idea of sharing common code, I think we should
> not mix both implementations in the same file.  How about moving
> the tree-specific functions to tree-ssa-ccp.c?
Okeydokey.

>
> When I started implementing tree-ssa, the flowgraph code also
> used a bunch of function pointers to re-use the existing code.
> It later turned out that the function pointers provided too much
> intrusion with little benefit.
>
> I see a lot of tiny changes to isolate IR-specific functions.  Is
> this really worth it?

Well, there is actually absolutely nothing IR specific about SSA-CCP, 
except the evaluation routine. The only reason i even need to use 
function pointers is differences in walking the fud chains vs walking 
the non-fud chains version of ssa.  And because the fast dce 
implementation doesn't really belong in this file.

>   Have you considered a new implementation
> instead?
Yes, it's just duplicating all the code.
There's really no point.

> Even if it means duplicating some code, I'm trying to
> figure out which option is easier to maintain in the future.
To be honest, I think it's easier to maintain ssa-ccp with function 
pointers.
Besides the only real difference being in the evaluation function, and 
walking the SSA, it would also enable us to vary the optimization 
performed based on -O level or something, or combine it with other 
optimizations just by plugging in a seperate function.


> If the common code is not really large, the added abstraction
> layer with function pointers may not be a good idea.
But it's almost *all* common code in reality.  part of the reason this 
isn't quite visible  is because their is a fast DCE implementation 
thrown into ssa-ccp.c, and because pieces of it need to be rewritten 
more to get rid of function pointers.


> I also
> don't particularly like the idea of tossing void pointers around
> (but I'm going to be posting about that in a separate thread).

>> I then implemented the functions for tree-ssa.
>> It doesn't remove the dead code, and has to conservatively assume phi
>> nodes parms to be active when they might not be (because we don't know
>> which to select for which incoming edge right now, so unless the phi
>> node is defined in one of the predecessors, and we know *that* edge
>> isn't executable, we can't say it's not executable).
>>
> This should be easy to fix by having PHI arguments know which
> edge they are coming from.
>
>> However, it propagates constants (anything really_constant_p
>> says is constant). The evaluation routine doesn't try to see if
>> array indices are variables/expressions with a constant value.
>> Other than that, all should be good.
>>
> You don't mention bootstrap/regression test results. Particulary,
> using -ftree-ssa.  On the branch we should make -O2 trigger the
> tree SSA transformations.
Bootstraps okay on powerpc-linux-gnu.
Never got to checking test results.

>
> Diego.



More information about the Gcc-patches mailing list