Question on changing IPA-PTA to an IPA_PASS

[Jan Hubicka]

> The reason this is not done is because the summaries (constraints)
> are huge, the solutions are even larger and the PTA solver doesn't
> scale to large units (so the LTRANS splitting makes it actually usable
> in the first place).

I did not spent that much time working on PTA as Richard, but it seems
to me that while this is true for current solver that runs on bitmaps,
the unification based PTA will scale (solving and stremaing should be
fast enough to be enabled by default).  If improved by context
sensitivity it should also give useful results.

So I think the right course of action is to make IPA-PTA to (optionally)
use unification based approach first, so it could run at -O2.  That Then
one can make it to work with summaries and run at WPA time.  Once this
is working one can work on right balance between precision and
performance.

There is a paper on the open64 implementation
https://yuleisui.github.io/publications/spe14.pdf
that looks close to what we could do.
> 
> Now - the reason you think of is likely that IPA transform will instantiate
> IPA clones and do inlining and transfering the IPA PTA solution to the
> such transformed IL is at best complicated.  That's true as well, of course,
> in fact IPA inlining and cloning will improve context sensitivity (by
> duplicating).

At high level I do not think it is so bad :)

Your IPA summary wil have constraints which will map to (probably
simplified) SSA graph.  If you clone function, you just duplicate the
summary.  Function signature changes (ipa-sra/ipa-cp) will need some
cooperation, but we already do similar things to keep jump functions
intact...

When inlining one needs to merge in the solution but that also seems
doable...

Honza

> 
> Note that in principle IPA summaries from other IPA passes are available
> and thus you could duplicate / rewrite constraints accordingly.
> 
> But the main reason we've not even tried to make IPA PTA a true IPA pass
> is because of the scalability issue.
> 
> Richard.