Question on changing IPA-PTA to an IPA_PASS

[Richard Biener]

On April 1, 2021 3:52:37 PM GMT+02:00, Erick Ochoa <eochoa@gcc.gnu.org> wrote:
>>
>> I don't think this would remove any problem that is present.
>>
>
>I have a problem understanding what you mean here because later on you
>state:
>
>> 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).
>
>So, I think you are agreeing with me that transferring the IPA PTA
>solution to the transformed IL is a big complication. So, going back
>to your previous statement "I don't think this would remove any
>problem that is present," does this mean that:
>
>1. this will not solve the "transfering the IPA PTA solution to the
>such transformed IL" problem?

This. 

>2. or "transfering the IPA PTA solution to the such transformed IL" is
>not a present problem?
>
>Sorry, just trying to understand what you are fully saying.
>
>Just to be more explicit, I believe (and might be wrong) that placing
>a new section of passes after the ipa-passes would now materialize all
>the new IL, and therefore when creating a new section, IPA-PTA would
>only see IL that will not be transformed. This gets rid of
>"transfering the IPA PTA solution to transformed IL" problem, because
>there is no more transformed IL. (But again, my understanding of some
>things might be wrong).

But that would mean running two ltrans and WPA phases. You can't (don't want to) materialize clones during WPA. 

>>
>> But the main reason we've not even tried to make IPA PTA a true IPA
>pass
>> is because of the scalability issue.
>>
>
>I didn't know this was the main reason! Thanks! I'm wondering, let's
>say that IPA PTA magically gets better performance. What would be the
>next steps after that? Is looking into the summaries and updating the
>constraints something that would be a good idea. (I think Hubicka
>agrees on doing that.) Or do you have some other hints/ideas about
>what would be a good implementation?

Honza already suggested a unification based solver. That would be an experiment to do. 

Richard.