On 10/2/18 8:58 PM, Qing Zhao wrote:
>
>> On Oct 2, 2018, at 1:09 PM, Richard Biener <richard.guenther@xxxxxxxxx> wrote:
>>
>>>>>
>>>>
>>>> Yes, such IPA analyzes should be disabled. we need to identify a
>>> complete list of such analyzes.
>>>
>>> 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.
>>
>> One could also compute the list of possibly affected functions from such semantic changes.
>
> theoretically, Yes.
>
> 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.
>
> B. enable all such optimizations, but compute the list of possibly affected functions from those IPA optimizations.
>
> 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.
>
> Or, we might need an option to provide the support for all the above?
That's basically equal to disabling the optimizations via -fno-ipa-ra -fno-ipa-*.
>
> -fease-live-patching={NONE|ALL|C1|C2|…|Cn}
>
> NONE: disable all IPA optimizations;
> ALL: enable all IPA optimizations, compute the list of affected functions;
> C1:
> C2:
> …
> Cn:
>
> C1 to Cn will be part of the optimizations, for exmaple, C1 might be only-static-inline, C2 might be inline-clone, etc.
As said, I would like to see listed all possibly problematic optimizations with their corresponding flags.
Having that we can think about an -flive-patching option that will disable bunch of these flags.
Note that we are not sure we already have flags for all IPA optimizations that can possibly
influence live-patching. We've been working on the listing.
Martin
>
> any comments or suggestions?
>
> Qing
>
>
>>
>> Richard.
>>
>>> Martin
>
