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. Qing > On Sep 26, 2018, at 6:12 AM, Alexander Monakov <amona...@ispras.ru> wrote: > > On Fri, 21 Sep 2018, Qing Zhao wrote: >> +2018-09-20 Qing Zhao <qing.z...@oracle.com> >> + >> + * cif-code.def (FUNCTION_EXTERN): New CIFCODE. >> + * common.opt (-finline-only-static): New option. >> + * doc/invoke.texi: Document -finline-only-static. >> + * ipa-inline.c (can_inline_edge_p): Control inlining based on >> + function's linkage. > > Note, I am not a reviewer. > > In my opinion, there's a problem with the patch that it looks like an ad-hoc, > incomplete solution. You said you need this change to help with building > livepatching-capable kernels, but it's not clear what exactly the issue with > inlining non-static functions is. Can you describe how the workflow looks like > so code duplication due to inlining static functions is not an issue, but > inlining non-static functions is a problem? Does using existing > -fno-inline-functions flag achieve something useful for your usecase? > > Please always make it clear what problem the patch is intended to solve and > help > reviewers see the connection between the problem and your solution. Look how > the > "XY problem" effect applies partially in this situation. > > https://en.wikipedia.org/wiki/XY_problem > http://xyproblem.info/ > > Alexander
