This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)
> On Oct 3, 2018, at 4:04 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>
>>
>> That was promised to be done by Honza Hubička. He's very skilled in IPA optimizations and he's aware
>> of optimizations that cause troubles for live-patching.
>
> :) I am not sure how skilful I am, but here is what I arrived to.
>
> We have transformations that are modeled as clonning, which are
> - inlining (can't be disabled completely because of always inline, but -fno-inline
> does most of stuff)
> - cloning (disabled via -fno-ipa-cp)
> - ipa-sra (-fno-ipa-sra)
> - splitting (-fno-partial-inlining)
> These should play well with Martin's tracking code
In addition to the above IPA transformations that cloned a routine, the following RTL transformation will clone a routine, too:
reorder-blocks-and-partition
this optimization will create .cold routines based on profiling feedback.
looks like that we also need to include this transformation into this category?
>
> We propagate info about side effects of function:
> - function attribute discovery (pure, const, nothrow, malloc)
> Some of this can be disabled by -fno-ipa-pure-const, but not all
> of it. Nothrow does not have flag but it is obviously not a concern
> for C++
> - ipa-pta (disabled by default, -fno-ipa-pta)
> - ipa-reference (list of accessed/modified global vars), disable by -fno-ipa-refernece
> - stack alignment requirements (no flag to disable)
> - inter-procedural register allocation (-fno-ipa-ra)
>
> We perform discovery of functions/variables with no address taken and
> optimizations that are not valid otherwise such as duplicating them
> or doing skipping them for alias analysis (no flag to disable)
>
> Identical code folding merges function bodies that are semanticaly equivalent
> and thus one can't patch one without patching another, -fno-ipa-icf
>
> Unreachable code/variable removal may be concern too (no flag to disable)
>
> Write only global variable discovery (no flag to dosable)
>
> Visibility changes with -flto and/or -fwhole-program
>
> We also have profile propagation (discovery of cuntions used only in cold regions,
> but that I guess is only performance issue not correctness)
> No flag to disable
are all the above analyzes guarded by AVAIL_INTERPOSABLE right now?
If NOT, should they be guarded by AVAIL_INTERPOSABLE?
Qing
>
> Honza
>
>>
>> Martin
>>
>>>
>>> thanks.
>>>
>>> Qing
>>>
>>