This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFC] Run PTA during early optimizations, do not re-run it after inlining
On Wed, 13 May 2009, Daniel Berlin wrote:
> On Wed, May 13, 2009 at 9:58 AM, Richard Guenther <firstname.lastname@example.org> wrote:
> > This patch implements merging points-to solutions during inlining.
> > This makes it possible to keep the points-to solutions from IPA-PTA
> > until after inlining.
> > As Honza has seen issues with placing FRE in early optimizations this
> > tries to stress the situation a bit by disabling the PTA run after
> > final inlining and instead relying on the inliner merging to produce
> > correct results. ?I have verified that it still produces good enough
> > results to not regress SPEC 2006 on x86_64 as well though I definitely
> > think that if we do not run IPA-PTA we should re-run local PTA after
> > final inlining. ?Currently PTA information degrades over time as
> > we cannot merge pruned points-to solutions across copies - this will
> > be fixed with the memory-model patches.
> > This patch misses copying the PTA solution to clones (I think), I plan
> > to fix that before committing. ?It also needs some fre testcase
> > adjustments that are now completely optimized out :(
> > Otherwise bootstrapped and tested on x86_64-unknown-linux-gnu.
> > Danny - how is (or is) local PTA and IPA-PTA supposed to interact?
> > It is necessary to "merge" solutions across inlining, no?
> You will actually get better solutions if you re-run IPA-PTA after
> inlining, since you don't have to merge contexts for the now-inlined
But that either requires a new LTO phase or will lose whole-program
information if done only on the current TU?
Certainly without LTO we can simply run IPA-PTA after inlining.
> This is true of any function that you've inlined that took pointer
> arguments and had multiple callers with different arguments.
> The solutions for the out-of-line version of the function will also be
> better for the same reason (it has one less callee whose arguments
Oh, indeed. I didn't think of that effect ;)
> There is some amount of incremental solving you can do to cut downt he
> time if you want to do this twice.
> You can just add the new constraints, rebuild the graph edges for the
> touched functions, reset the points-to solutions on the functions that
> you inlined from or to, and re-solve the graph.
Ok, that would require keeping the graph. I'm not sure how/if that
would work with LTO/WHOPR.
So, do you think the patch is moot? (It certainly is during early
inlining as we re-compute the information anyway)
Can you think of anything besides the function-wide escaped/callused
solutions that gets invalid in the caller after inlining the callee
(with all the callee SSA name pointers pointing to anything in the