GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

[Richard Biener]

On Wed, Oct 3, 2018 at 6:00 PM Qing Zhao <qing.zhao@oracle.com> wrote:
>
>
> > On Oct 3, 2018, at 5:19 AM, Martin Jambor <mjambor@suse.cz> 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
> >
>