> On Oct 7, 2022, at 9:03 AM, Jan Hubicka <hubi...@ucw.cz> wrote: > >>> WPA is Whole Program Analysis? >> >> Yes. >> >>> Okay, then It will promote all static function to extern functions. That’s >>> reasonable. >> >> No, all extern functions to static functions. >> >>> Is it hard to preserve the original “static” visibility in the IR? >> >> 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.
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? > > 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? > 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. 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
