This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Run PTA during early optimizations, do not re-run it after inlining
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Richard Guenther <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 13 May 2009 14:36:27 -0400
- Subject: Re: [PATCH][RFC] Run PTA during early optimizations, do not re-run it after inlining
- References: <alpine.LNX.2.00.0905131551310.25789@zhemvz.fhfr.qr>
On Wed, May 13, 2009 at 9:58 AM, Richard Guenther <rguenther@suse.de> 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
function.
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
matter).
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.