From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Wahren Subject: Re: [PATCH] compiler: enable CONFIG_OPTIMIZE_INLINING forcibly Date: Sat, 12 Oct 2019 12:15:42 +0200 Message-ID: <35643c7e-94e9-e410-543b-a7de17b59a32@gmx.net> References: <20191001092823.z4zhlbwvtwnlotwc@willie-the-truck> <20191001170142.x66orounxuln7zs3@willie-the-truck> <20191001175512.GK25745@shell.armlinux.org.uk> <20191001181438.GL25745@shell.armlinux.org.uk> <20191003163606.iqzcxvghaw7hdqb5@willie-the-truck> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20191003163606.iqzcxvghaw7hdqb5@willie-the-truck> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Will Deacon , Linus Torvalds Cc: Geert Uytterhoeven , Nick Desaulniers , Russell King - ARM Linux admin , Masahiro Yamada , Nicolas Saenz Julienne , Andrew Morton , Ingo Molnar , Borislav Petkov , Miguel Ojeda , linux-arch , LKML , Catalin Marinas , Kees Cook , Arnd Bergmann , clang-built-linux List-Id: linux-arch.vger.kernel.org Hi, Am 03.10.19 um 18:36 schrieb Will Deacon: > On Wed, Oct 02, 2019 at 01:39:40PM -0700, Linus Torvalds wrote: >> On Wed, Oct 2, 2019 at 5:56 AM Geert Uytterhoeven wrote: >>>> Then use the C preprocessor to force the inlining. I'm sorry it's not >>>> as pretty as static inline functions. >>> Which makes us lose the baby^H^H^H^Htype checking performed >>> on function parameters, requiring to add more ugly checks. >> I'm 100% agreed on this. >> >> If the inline change is being pushed by people who say "you should >> have used macros instead if you wanted inlining", then I will just >> revert that stupid commit that is causing problems. >> >> No, the preprocessor is not the answer. >> >> That said, code that relies on inlining for _correctness_ should use >> "__always_inline" and possibly even have a comment about why. >> >> But I am considering just undoing commit 9012d011660e ("compiler: >> allow all arches to enable CONFIG_OPTIMIZE_INLINING") entirely. The >> advantages are questionable, and when the advantages are balanced >> against actual regressions and the arguments are "use macros", that >> just shows how badly thought out this was. > It's clear that opinions are divided on this issue, but you can add > an enthusiastic: > > Acked-by: Will Deacon > > if you go ahead with the revert. I'm all for allowing the compiler to > make its own inlining decisions, but not when the potential for > miscompilation isn't fully understood and the proposed alternatives turn > the source into an unreadable mess. Perhaps we can do something different > for 5.5 (arch opt-in? clang only? invert the logic? work to move functions > over to __always_inline /before/ flipping the CONFIG option? ...?) what's the status on this? In need to prepare my pull requests for 5.5 and all recent kernelci targets (including linux-next) with bcm2835_defconfig are still broken. Stefan > > Will From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net ([212.227.17.22]:50579 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726555AbfJLKVM (ORCPT ); Sat, 12 Oct 2019 06:21:12 -0400 Subject: Re: [PATCH] compiler: enable CONFIG_OPTIMIZE_INLINING forcibly References: <20191001092823.z4zhlbwvtwnlotwc@willie-the-truck> <20191001170142.x66orounxuln7zs3@willie-the-truck> <20191001175512.GK25745@shell.armlinux.org.uk> <20191001181438.GL25745@shell.armlinux.org.uk> <20191003163606.iqzcxvghaw7hdqb5@willie-the-truck> From: Stefan Wahren Message-ID: <35643c7e-94e9-e410-543b-a7de17b59a32@gmx.net> Date: Sat, 12 Oct 2019 12:15:42 +0200 MIME-Version: 1.0 In-Reply-To: <20191003163606.iqzcxvghaw7hdqb5@willie-the-truck> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-arch-owner@vger.kernel.org List-ID: To: Will Deacon , Linus Torvalds Cc: Geert Uytterhoeven , Nick Desaulniers , Russell King - ARM Linux admin , Masahiro Yamada , Nicolas Saenz Julienne , Andrew Morton , Ingo Molnar , Borislav Petkov , Miguel Ojeda , linux-arch , LKML , Catalin Marinas , Kees Cook , Arnd Bergmann , clang-built-linux Message-ID: <20191012101542.F6nqZC_FublrKtOVFJG5t8Kt8DDHDanszxN9RYIi5SM@z> Hi, Am 03.10.19 um 18:36 schrieb Will Deacon: > On Wed, Oct 02, 2019 at 01:39:40PM -0700, Linus Torvalds wrote: >> On Wed, Oct 2, 2019 at 5:56 AM Geert Uytterhoeven wrote: >>>> Then use the C preprocessor to force the inlining. I'm sorry it's not >>>> as pretty as static inline functions. >>> Which makes us lose the baby^H^H^H^Htype checking performed >>> on function parameters, requiring to add more ugly checks. >> I'm 100% agreed on this. >> >> If the inline change is being pushed by people who say "you should >> have used macros instead if you wanted inlining", then I will just >> revert that stupid commit that is causing problems. >> >> No, the preprocessor is not the answer. >> >> That said, code that relies on inlining for _correctness_ should use >> "__always_inline" and possibly even have a comment about why. >> >> But I am considering just undoing commit 9012d011660e ("compiler: >> allow all arches to enable CONFIG_OPTIMIZE_INLINING") entirely. The >> advantages are questionable, and when the advantages are balanced >> against actual regressions and the arguments are "use macros", that >> just shows how badly thought out this was. > It's clear that opinions are divided on this issue, but you can add > an enthusiastic: > > Acked-by: Will Deacon > > if you go ahead with the revert. I'm all for allowing the compiler to > make its own inlining decisions, but not when the potential for > miscompilation isn't fully understood and the proposed alternatives turn > the source into an unreadable mess. Perhaps we can do something different > for 5.5 (arch opt-in? clang only? invert the logic? work to move functions > over to __always_inline /before/ flipping the CONFIG option? ...?) what's the status on this? In need to prepare my pull requests for 5.5 and all recent kernelci targets (including linux-next) with bcm2835_defconfig are still broken. Stefan > > Will