> On Oct 3, 2018, at 5:19 AM, Martin Jambor <mjambor@xxxxxxx> wrote: > > Hi, > > On Tue, Oct 02 2018, Qing Zhao wrote: >> So, here comes the next question: >> >> what will be the better approach for helping live-patching? >> >> A. disable all the optimization/analyzes that changing a function based on other functions. this includes most of >> the IPA optimizations, inlining, cloning, ipa side effect analysis, etc. > > We came to the conclusion that we do not want to disable (any) inlining > - primarily for performance reasons but also because of always_inline. > When you have to deal with inlining, you can use the same mechanism for > IPA-CP clones, IPA-SRA and anything that creates clones and callers need > to be patched. > > Always_inline is also the reason why I would discourage anyone from > attempting this, it looks too much like an irresolvable conflict. Okay. However, there are also other users of live-patching who request only inlining static routines to control the code size explosion and debugging complexity as the start of the whole discussion. in addition to control inlining, I am not sure whether we want to control ipa-cp, ipa-sra, etc to further control the code size and debugging complexity? we should also include such request into this work. > >> >> B. enable all such optimizations, but compute the list of possibly affected functions from those IPA optimizations. > > Although certainly possible, we came to the conclusion that it would be > impractical to attempt to track all decisions affected by, say, a > function being pure, or a variable read-only, etc. Impractical to the > point when at least I personally would also discourage anyone from > attempting this too, it would be necessary to record this info deep > inside AA, VRP, who know what else, and keep it up to date. I think that theoretically the compiler should be able to do this. But the impacted routine list might be huge. that also lead problems of code size explosion and debugging complexity. > >> >> C. enable part of them and disable the other part of them. for the part of enabled ones, compute the list of possibly affected functions >> from them. > > Which means we would like to go this route. Qing > > Martin >
