From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux admin Subject: Re: [PATCH] compiler: enable CONFIG_OPTIMIZE_INLINING forcibly Date: Tue, 1 Oct 2019 18:55:12 +0100 Message-ID: <20191001175512.GK25745@shell.armlinux.org.uk> References: <20190930112636.vx2qxo4hdysvxibl@willie-the-truck> <20190930121803.n34i63scet2ec7ll@willie-the-truck> <20191001092823.z4zhlbwvtwnlotwc@willie-the-truck> <20191001170142.x66orounxuln7zs3@willie-the-truck> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Nick Desaulniers Cc: Will Deacon , Masahiro Yamada , Linus Torvalds , Nicolas Saenz Julienne , Andrew Morton , Ingo Molnar , Borislav Petkov , Miguel Ojeda , linux-arch , LKML , Catalin Marinas , Stefan Wahren , Kees Cook List-Id: linux-arch.vger.kernel.org On Tue, Oct 01, 2019 at 10:44:43AM -0700, Nick Desaulniers wrote: > I apologize; I don't mean to be difficult. I would just like to avoid > surprises when code written with the assumption that it will be > inlined is not. It sounds like we found one issue in arm32 and one in > arm64 related to outlining. If we fix those two cases, I think we're > close to proceeding with Masahiro's cleanup, which I view as a good > thing for the health of the Linux kernel codebase. Except, using the C preprocessor for this turns the arm32 code into yuck: 1. We'd need to turn get_domain() and set_domain() into multi-line preprocessor macro definitions, using the GCC ({ }) extension so that get_domain() can return a value. 2. uaccess_save_and_enable() and uaccess_restore() also need to become preprocessor macro definitions too. So, we end up with multiple levels of nested preprocessor macros. When something goes wrong, the compiler warning/error message is going to be utterly _horrid_. Now, as to whether an __attribute__((always_inline)) can or can not be inlined... `always_inline' Generally, functions are not inlined unless optimization is specified. For functions declared inline, this attribute inlines the function even if no optimization level is specified. Is this another instance of the compiler folk changing the rules of already documented semantics? This says nothing about "might not be inlined if someone passes some random combination of -f flags". -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from pandora.armlinux.org.uk ([78.32.30.218]:41812 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726554AbfJARzc (ORCPT ); Tue, 1 Oct 2019 13:55:32 -0400 Date: Tue, 1 Oct 2019 18:55:12 +0100 From: Russell King - ARM Linux admin Subject: Re: [PATCH] compiler: enable CONFIG_OPTIMIZE_INLINING forcibly Message-ID: <20191001175512.GK25745@shell.armlinux.org.uk> References: <20190930112636.vx2qxo4hdysvxibl@willie-the-truck> <20190930121803.n34i63scet2ec7ll@willie-the-truck> <20191001092823.z4zhlbwvtwnlotwc@willie-the-truck> <20191001170142.x66orounxuln7zs3@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Nick Desaulniers Cc: Will Deacon , Masahiro Yamada , Linus Torvalds , Nicolas Saenz Julienne , Andrew Morton , Ingo Molnar , Borislav Petkov , Miguel Ojeda , linux-arch , LKML , Catalin Marinas , Stefan Wahren , Kees Cook Message-ID: <20191001175512.CK7rxkqX96iCa0wgBI-5x1M4UyODatGqdze_J-8Y_bk@z> On Tue, Oct 01, 2019 at 10:44:43AM -0700, Nick Desaulniers wrote: > I apologize; I don't mean to be difficult. I would just like to avoid > surprises when code written with the assumption that it will be > inlined is not. It sounds like we found one issue in arm32 and one in > arm64 related to outlining. If we fix those two cases, I think we're > close to proceeding with Masahiro's cleanup, which I view as a good > thing for the health of the Linux kernel codebase. Except, using the C preprocessor for this turns the arm32 code into yuck: 1. We'd need to turn get_domain() and set_domain() into multi-line preprocessor macro definitions, using the GCC ({ }) extension so that get_domain() can return a value. 2. uaccess_save_and_enable() and uaccess_restore() also need to become preprocessor macro definitions too. So, we end up with multiple levels of nested preprocessor macros. When something goes wrong, the compiler warning/error message is going to be utterly _horrid_. Now, as to whether an __attribute__((always_inline)) can or can not be inlined... `always_inline' Generally, functions are not inlined unless optimization is specified. For functions declared inline, this attribute inlines the function even if no optimization level is specified. Is this another instance of the compiler folk changing the rules of already documented semantics? This says nothing about "might not be inlined if someone passes some random combination of -f flags". -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up