Re: [PATCH] IPA: support -flto + -flive-patching=inline-clone

[Jan Hubicka <hubicka@ucw.cz>]

> >> Probably not hard, and the IPA pass adjusting visbility could as well
> >> mark the functions
> >> as not to be inlined with -flive-patching=inline-only-static.
> >> 
> >>>> 
> >>>> OTOH inline-only-static could disable WPA inlining and do all inlining early ...
> >>> 
> >>> Inline-only-static ONLY inlines static functions, how can it disable WPA inlining? Don’t quite understand here.
> >> 
> >> it's a flag so it can be used to control other things
> > 
> > GCC has two inliners
> > 1) ealry inlininer which happens at compile time and is quite
> > restricted only to obvious cases (always_inline, flatten and very small
> > functions)
> > 2) IPA inlining happening at link-time (WPA) which is using greedy
> > algorithm and makes more complicated code size/speed tradeoffs
> > Indeed betwen 1 and 2 previously global functions may become static by
> > resolution info (they won't currently with kernel since we do
> > incremental linking).  We could easily keep track of originally static
> > functions and promoted to static functions and make IPA inlining to
> > honnor the patch.
	       ^^^^ I mean -flive-patching=inline-only-static flag
> 
> Yes, this is similar as Studio compiler (an early inliner and a IPA inliner) 
> But I still don’t quite understand why during IPA inlining, extern functions need to be changed to static functions?
>  (in Studio compiler, it’s opposite, static functions are all promoted to extern functions to enable inter-procedural inlining)
> Is there a file I can read to understand more details on this?

In GCC WPA stage takes all compilation units and create a new combined
translation unit.  This has same kind of symbol table as if it came all
from a single source file.  So if resolution file tells us that a given
symbol is not used outside the LTO bytecode (when one links final binary
linker knows if there was other use and similar for shared libraries if
symbol is hidden) we promote symbol to static.  This lets us to optimize
it better: change calling conventions, remove offline copy if all calls
was inlined, propagate various information about it.

Since from this moment on the whole translation unit behaves as single
source file it is not problem to inline static functions cross-modle.

Later we partition the combined unit to do rest of compilation in
parallel and at this stage some static symbols can be changed to hidden
symbols if they are used by multiple partitioning.
> 
> > 
> > I however wonder how much LTO optimization would remain. If we disable
> > all inter-module inlining
> 
> Oh, wait,  so, demoting “extern” functions to “static” functions in GCC’s IPA inlining is to disable inter-module inlining? 
> Why? Is there any technical issue with inter-module inlining in GCC? 

No I suppose it is just different organization of LTO from Studio
compiler.  Perhaps studio compiler still combine according to original
source-level compilation units and then cross-module inlining of
function A may cause function B to be promoted to public in a case
originally both A and B were in same compilation unit and B was static?
> 
> 
> > and with live patching we also disable most of
> > other optimization,
> 
> Yes, with live-patching, most of the IPA optimization need to be disabled. But this functionality is needed, right? When user requests live-patching support, 
> They should know that most of IPA optimization will be disabled.

Question is how much useful is to biuld with -flto then.  I woudl say that
close to 90% of performance benefits from LTO originates from cross-module
inlining. Most of code size benefits are due to 
 - removing unreachable code,
 - inlining functions called once (with whole program knowledge)
 - removing offline function bodies if all calls has been inlined. and
 - identical code folding

Other IPA optimizations we implement (function flags discovery, mod-ref
etc.) accounts for smaller portion of perofmance & size.

If you block cross-module inlininig and all kind of inter-procedural
optimizations you lose, I believe, all of the goodies above except for
removal of unreachable code.

While this is important for some C++ code with a lot of template
instantiations, I am not sure how many completely dead functions kernel has.
So what use cases you expect for -flto -flive-patching=inline-only-static?
Honza
> 
> Qing
> 
> > I think basically only unreachable code removal will
> > remain and possibly some propagation of "coldness" across the code.
> > 
> > I can implement this incrementally.
> > Martin, if live patching is happy about some symbols being promoted
> > static, the patch is OK.
> > Honza
>