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

[Qing Zhao]

> 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.

> 
>> 
>> 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
>