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