On April 1, 2021 3:52:37 PM GMT+02:00, Erick Ochoa <eoc...@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.
