[PATCH][RFC] Run PTA during early optimizations, do not re-run it after inlining

[Daniel Berlin]

On Wed, May 13, 2009 at 3:02 PM, Richard Guenther <rguenther@suse.de> wrote:
> 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?

The former was the idea ;)

>
> Certainly without LTO we can simply run IPA-PTA after inlining.
>

Yes

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

It's certainly trickier in the face of these.

> So, do you think the patch is moot?  (It certainly is during early
> inlining as we re-compute the information anyway)

I have no problem with the patch as it is. At some point, we are going
to have to have an update interface to PTA info and there will be
optimizations where the best we can do is merge solutions. I'm not
sure inlining is one of them, but for now, i don't think you should be
forced to do more work ;)

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

In the face of regular inlining, not offhand but i haven't sat down and tried.
In the face of conditional inlining of indirect calls, ya, there is
plenty that can change :(

--Dan