On Wed, Oct 3, 2018 at 6:00 PM Qing Zhao <qing.zhao@xxxxxxxxxx> wrote: > > > > 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. I think it boils down to have a "global" lattice of non-VARYING-X "because of $FN" for each of the analyses X properly propagated along the callgraph. Something as "simple" as annotating each function output or inlined with its lattice state "PURE, 1st param ~[0,0]", etc. could be helpful to spot differences before/after the patch and raise a flag. Richard. > > > >> > >> 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 > > >
