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