> @honza: PING
>
> On 10/3/18 12:53 PM, Martin Liška wrote:
> > On 10/3/18 11:04 AM, Jan Hubicka 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.
> >
> > Heh! Thanks for the analysis.
> >
> >>
> >> 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
> >
> > I hope so!
> >
> >>
> >> 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.
> >
> > Would it be possible to add option for the remaining ones?
Sure, I can prepare patch unless you beat me :)
> >
> > Nothrow does not have flag but it is obviously not a concern
> >> for C++
> >
> > s/C++/C?
Yep 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)
> >
> > Would it be possible to add flag for it? Can you please point to a location where
> > the optimization happen?
In expand_call
/* Figure out the amount to which the stack should be aligned. */
preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
if (fndecl)
{
struct cgraph_rtl_info *i = cgraph_node::rtl_info (fndecl);
/* Without automatic stack alignment, we can't increase preferred
stack boundary. With automatic stack alignment, it is
unnecessary since unless we can guarantee that all callers will
align the outgoing stack properly, callee has to align its
stack anyway. */
if (i
&& i->preferred_incoming_stack_boundary
&& i->preferred_incoming_stack_boundary < preferred_stack_boundary)
preferred_stack_boundary = i->preferred_incoming_stack_boundary;
}
> >
> >> - 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)
> >
> > Can you be please more verbose here? What optimizations do you mean?
See ipa_discover_readonly_nonaddressable_vars. If addressable bit is
cleared we start analyzing uses of the variable via ipa_reference or so.
If writeonly bit is set, we start removing writes to the variable and if
readonly bit is set we skip any analysis about whether vairable changed.
> >
> >>
> >> Identical code folding merges function bodies that are semanticaly equivalent
> >> and thus one can't patch one without patching another, -fno-ipa-icf
> >
> > Agree, I recommend disabling that.
> >
> >>
> >> Unreachable code/variable removal may be concern too (no flag to disable)
> >
> > For functions that should be fine and handled by my script.
> > For variables can be problem when a variable becomes alive But that
> > should be extremely rare for live-patching.
> >
> >>
> >> Write only global variable discovery (no flag to dosable)
> >
> > Similarly.
> >
> >>
> >> 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
> >
> > Hope these 2 does not happen for current Linux kernel.
2 will happen in kernel. We will try to propagate cold code
inter-procedurally based on what we think will be undefined effect at
runtime. Still i guess it is not big deal as it only affects
size optimization.
Honza
> >
> > Martin
> >
> >>
> >> Honza
> >>
> >>>
> >>> Martin
> >>>
> >>>>
> >>>> thanks.
> >>>>
> >>>> Qing
> >>>>
> >>>
> >
>
