This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <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.

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.

Sure.

> 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).

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
inlined copy)?

Thanks,
Richard.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]