On Thu, Apr 1, 2021 at 2:50 PM Erick Ochoa via Gcc <gcc@gcc.gnu.org> wrote: > > Hi, > > just a high level question. I know that IPA-PTA is a SIMPLE_IPA_PASS > and that ideally it would be better as an IPA_PASS. I understand that > one of the biggest challenges of changing IPA-PTA to an IPA_PASS is > that on the current LTO framework, the LTRANS stage can happen at the > same time for multiple transformations. This means (I think) that if > IPA-PTA computed the points-to sets during WPA, during LTRANS there > can be new variables, or modified function bodies that therefore no > longer correspond to the computed IPA-PTA. > > However, it seems that there's a simpler way to change IPA-PTA to an > IPA_PASS. This is by just introducing another section of > "all_regular_ipa_passes". Something like (not sure if the name inside > the brackets has to be unique) > > INSERT_PASSES_AFTER (all_regular_ipa_passes) > // normal stuff > TERMINATE_PASS_LIST (all_regular_ipa_passes) > INSERT_PASSES_AFTER (all_regular_ipa_passes) > NEXT_PASS (pass_ipa_pta); > TERMINATE_PASS_LIST (all_regular_ipa_passes) > > I understand that this still singles out IPA-PTA as being "special",
I don't think this would remove any problem that is present. > but I am wondering if this is something that has been discussed > previously. The changes in the implementation on IPA-PTA should be > something like: > > 1. LGEN: in summaries store the constraint variables that GCC is > finding by inspecting gimple > 2. WPA: actually solve the constraint variables and store only the > solutions to the constraint variables in another summary > 3. LTRANS: read from the summary and pass the information to gimple > > The advantage I see to this is that the precision of IPA-PTA would be > equal to using -flto-partition=none but without actually using that > flag and possibly some compile time speedup (when compared to > -flto-partition=none because parallel reading and writing of > summaries). Again, just an idea and I just want to understand if this > has been discussed before and why it is or might not be something that > you guys want. 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). 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). 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.
