From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AF17A388CC1B; Mon, 19 Oct 2020 15:33:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AF17A388CC1B From: "marxin at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined Date: Mon, 19 Oct 2020 15:33:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 10.1.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 15:33:43 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97445 --- Comment #18 from Martin Li=C5=A1ka --- (In reply to Jan Hubicka from comment #17) > > The following happens: > >=20 > > get_order is called by kmalloc_large which is called in kmalloc. And km= alloc > > calls the function for larger allocations. Problem is that we eliminate= all > > calls to get_order late > >=20 > > pipe.i.108t.thread1:;; Function get_order (get_order, funcdef_no=3D295, > > decl_uid=3D4528, cgraph_uid=3D300, symbol_order=3D303) > > pipe.i.108t.thread1:get_order (long unsigned int size) > > pipe.i.108t.thread1: _125 =3D get_order (_114); > > pipe.i.108t.thread1: _67 =3D get_order (_56); > > pipe.i.109t.cdce:;; Function get_order (get_order, funcdef_no=3D295, > > decl_uid=3D4396, cgraph_uid=3D300, symbol_order=3D303) > > pipe.i.109t.cdce:get_order (long unsigned int size) > >=20 > > so remove_unreachable_nodes is not called any more. > Yep, that is by design - we are already outputting functions to > assembler file, so there is not much we can do at this moent. Option > wold be to do threading early of course. How often this happen in > practice? >=20 > Also note that -Winline outputs reasons why the static inline is not You are right, this is printed: gcc -O2 pipe.i -c -fdump-tree-all -Winline In file included from ./arch/x86/include/asm/page.h:77, from ./arch/x86/include/asm/thread_info.h:12, from ./include/linux/thread_info.h:38, from ./arch/x86/include/asm/preempt.h:7, from ./include/linux/preempt.h:78, from ./include/linux/spinlock.h:51, from ./include/linux/mmzone.h:8, from ./include/linux/gfp.h:6, from ./include/linux/mm.h:10, from fs/pipe.c:8: ./include/linux/slab.h: In function =E2=80=98alloc_pipe_info=E2=80=99: ./include/asm-generic/getorder.h:29:146: warning: inlining failed in call to =E2=80=98get_order=E2=80=99: --param max-inline-insns-single limit reached = [-Winline] 29 | static inline __attribute_const__ int get_order(unsigned long size) |=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 ^= =20=20=20=20=20=20 In file included from fs/pipe.c:11: ./include/linux/slab.h:482:30: note: called from here 482 | unsigned int order =3D get_order(size); | ^~~~~~~~~~~~~~~ In file included from ./arch/x86/include/asm/page.h:77, from ./arch/x86/include/asm/thread_info.h:12, from ./include/linux/thread_info.h:38, from ./arch/x86/include/asm/preempt.h:7, from ./include/linux/preempt.h:78, from ./include/linux/spinlock.h:51, from ./include/linux/mmzone.h:8, from ./include/linux/gfp.h:6, from ./include/linux/mm.h:10, from fs/pipe.c:8: ./include/linux/slab.h: In function =E2=80=98pipe_resize_ring=E2=80=99: ./include/asm-generic/getorder.h:29:146: warning: inlining failed in call to =E2=80=98get_order=E2=80=99: --param max-inline-insns-single limit reached = [-Winline] 29 | static inline __attribute_const__ int get_order(unsigned long size) |=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 ^= =20=20=20=20=20=20 In file included from fs/pipe.c:11: ./include/linux/slab.h:482:30: note: called from here 482 | unsigned int order =3D get_order(size); | ^~~~~~~~~~~~~~~ > inlined (which is also by design a decision of the inliner heuristics). > I suppose here the inliner sees the function called multiple times and > since it is quite long it decides to keep it offline. Opitmizing all > references late if of course unfortunate. >=20 > Honza=