> On Sep 26, 2018, at 10:16 AM, Alexander Monakov <amona...@ispras.ru> wrote: > > On Wed, 26 Sep 2018, Qing Zhao wrote: > >> Alexander, >> >> thanks for the questions. >> >> Yes, we had some discussion on the questions you raised during the review of >> the initial patch back to 9/11/2018. >> please take a look at those discussions at: >> >> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00549.html >> <https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00549.html> >> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00787.html >> <https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00787.html> >> >> and let me know if those discussion still does not answer your questions. > > Thank you. Yes, it is still unclear to me why restricting inlining to static > functions noticeably helps in your case. Is it because you build the kernel > with LTO? Otherwise effects from inlining are limited to one compilation unit, > except for functions defined in headers. But for those, the kernel > uses 'static inline' anyway, so the patch wouldn't change anything.
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. hope this is helpful. 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
