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. OTOH inline-only-static could disable WPA inlining and do all inlining early ... Richard, > > thanks. > > Qing > > > > > Martin > > > >> > >> thanks. > > >
