On 10/6/22 10:29, Richard Biener wrote: > On Wed, Oct 5, 2022 at 8:18 PM Qing Zhao via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: >> >> >> >>> On Oct 5, 2022, at 1:36 PM, Martin Liška <mli...@suse.cz> wrote: >>> >>> On 10/5/22 16:50, Qing Zhao wrote: >>>> I have two questions on this: >>> >>> Hello. >>> >>>> >>>> 1. What’s the motivation to enable -flive-patching with -flto? Is there >>>> any application that will try -flive-patching with -flto now? >>> >>> We're planning supporting GCC LTO Linux kernel support, so that's one >>> motivation. And the second one is a possible >>> use in user-space livepatching. Note majority of modern distros default to >>> -flto (openSUSE, Fedora, Debian, Ubuntu, ...). >> >> Okay, I see. That’s reasonable. >>> >>>> >>>> 2. Why only enable -flive-patching=inline-clone with -flto? >>> >>> Because the inline-only-static level (which you added/requested) would have >>> to properly >>> block inter-procedural inlining that happens in LTO >>> (can_inline_edge_by_limits_p) and >>> I'm not sure it would be properly blocked. So, feel free to extend my patch >>> if you want? >> >> -flive-patching=inline-only-static >> >> Only enable static functions inlining, all the inlining of external visible >> functions are blocked, So, LTO should be compatible with this naturally >> without any issue, I think. >> >> i.e, when "-flive-patching=inline-only-static -flto" present together, all >> the inter-procedural inlining should be automatically blocked by >> -flive-patching=inline-only-static already. >> >> Do I miss anything here? > > WPA will promote externally visible functions static when all accesses > are from LTO IR, I don't think we preserve > the "original" visibility for IPA inlining heuristics.
That said, can we go with my original patch? > > OTOH inline-only-static could disable WPA inlining and do all inlining early > ... And this can be extended by Oracle folks if they are interested in -flive-patching=inline-only-static combined with LTO. Martin > > Richard, > >> >> thanks. >> >> Qing >> >>> >>> Martin >>> >>>> >>>> thanks. >>> >>
