[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