> On Sep 26, 2018, at 6:07 PM, Alexander Monakov <amona...@ispras.ru> wrote: > > On Wed, 26 Sep 2018, Qing Zhao wrote: >> The request is for application developers who want to use gcc's online >> patching feature. >> >> Today, developers can turn off inlining and deliver just the patched >> routine. They >> can also allow all inlining and deliver the patched routine and all the >> routines >> that the patched routine was inlined into. >> >> completely turning off inlining will sacrifice too much run-time >> performance. completely >> enable inlining, on the other hand, will have the potential issues with code >> size, complexity and >> debuggability for the online patching. >> >> the proposed option provides a compromised solution for the above issues. >> and enable more >> developers to utilize gcc’s online patching feature. > > From this explanation it sounds to me that what you really need is -Os-like > behavior for IPA passes, without enabling -Os for gimple/rtl passes, as I > mentioned in my previous email. Honza, how does that sound?
I don’t think a -Os-like option will do the job. As Jeff already mentioned in a very previous email: “Presumably one of the cases where this capability is really helpful is things like ksplice. If you have a function with global scope that has been potentially inlined, then it's a lot harder track down those inlining points at DTRT. We ran into this internally when looking at hot patching some of the spinlock code in the kernel. It would have been real helpful if the kernel had been compiled with this kind of option :-) So conceptually I can see value in this kind of option. “ so, specially control inlining on static/global will be helpful to online patch. Qing > >>> If the original issue is that inlining duplicates code, wouldn't it be >>> better >>> solved by a switch that instructs inlining heuristics to inline as if for >>> -Os, >>> without enabling -Os for other passes? > > Alexander
