Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp275690ybp; Thu, 3 Oct 2019 13:25:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqyybUGP7tx59pwcQx0QxofYIRYMF1apQ2ZhUW8itFvgYnSErInNYTIFhy9DpTR1eEJ7sttw X-Received: by 2002:aa7:cb46:: with SMTP id w6mr12131131edt.238.1570134312367; Thu, 03 Oct 2019 13:25:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570134312; cv=none; d=google.com; s=arc-20160816; b=QBOTVRzPTtQAMPu+3Kyytj0mgMkSztn+Pk1InIf4xiau/qPW8RPTmZ8/3FuzfFQ4Pj K5M2pYdBRHPrFqUVohDUzj5cFOMArkkMAPN7tRJUCprMayx68UGVIgcX/2/Bw16Ou23c Tqfx2ozBvKqbMwm3JYzOrpb0IRBbUsjC96KvSOIN2d63VTQb6SooEEAxdynaCcHJipEC r4iM1jWVOThNRZpW/eER+tg+Ou3SAyLHoK1D7xxER8nD2Z8Mt//GkiKvpYr4UeDdm0Qp WmwMZuZAy7SPyQCkbh/b3TFZs/ZlUQKtbUI3H6cHBdzxjbrPqUTSwZXxEoyBDY7ebFU0 Rixw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=jDZRfMkXuS+gCx9+RspTMOpPYXHsN1Tk1N0L1DUZ7HM=; b=z2dAGWNyV5RoH4mO6XaXBH9VNTeC3524OIpThup271B39l77TQsC3+dlr+fCuCap9P X01DNtKKjqAUMGv8AFyHr8gRMTJUWrlQaEjEOrOUGupcEo07eCk2kwAgKCQw22TTFjG/ OOkF9vLS0IR8NLobPSxiswauDU0gbLAkdAySs40CmHGNMrXJhyrw2Fq3x/HAd1ipLf6z KRfrJsBOtGefneqSSN7i7jfm2K6IdxCyWdQKfHeQQNJ6c0WpYlag5sluu03N4MEWiXQG s9M7Ud1NJaer9d4dT0p+/vkxoiytPIXMrtS7DHsaoHGK5XJQ5vympcCTJ7ey0kUenUn5 qfMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mF4FYXDK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j28si2478917eda.161.2019.10.03.13.24.48; Thu, 03 Oct 2019 13:25:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mF4FYXDK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389360AbfJCUVY (ORCPT + 99 others); Thu, 3 Oct 2019 16:21:24 -0400 Received: from mail-lf1-f67.google.com ([209.85.167.67]:35442 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732848AbfJCUVY (ORCPT ); Thu, 3 Oct 2019 16:21:24 -0400 Received: by mail-lf1-f67.google.com with SMTP id w6so2834277lfl.2; Thu, 03 Oct 2019 13:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jDZRfMkXuS+gCx9+RspTMOpPYXHsN1Tk1N0L1DUZ7HM=; b=mF4FYXDKIuGkHD4EoUdMIdXsBYgzvi2LuBwfqYqMCEBS8q9qeEukZ0LiJd751oxxUH HTmLWqSXP2j3DeCXIv0ZS0XYhO30p9xd1DYm3jlV1dl/RYbs4TI88eFtycOHMnyXHnG6 kevCuCh9EplsKm4v8y9I+MyQncF7mzXrUqvhjbohSHLi0n66QMb38MS+UPLnpK8nmZoj bRm0A4UNPdl5uOh2HvjST/7KnIAea15FnLsEz1bKL82OvSlXXBkmcZjcidxvtrjZ3aoq cQIMppO8edkchgIj7SREuHwHCk4lSXEvWxRaBwHNxKEuRXSgZS7c26zKK1AyD38jIqgB F1tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jDZRfMkXuS+gCx9+RspTMOpPYXHsN1Tk1N0L1DUZ7HM=; b=tWi4xcqaE16qCix2eViA9H72MyNw7+TtYDga0N9pnSRLB9aUmAD4m+yYmxiSU2bXw1 vIyv0hfWjLdx5G2i1hO2yWLKE2fbUTJYeiVTZAagp2p8UAV5AhED9zP7ajuwyPezbfL6 ffnvCex0T/ibePhBFtOV2qwjXNhffsS4ni/Skcq/bhhYIm/cPLVbyRyy82MWonHP7CdV +2R3vE4vlrXlwxNsrIlHfx3X4Ois1vPo+Rz9bD6iUeGLw4SOfqk0XjPtnNED3pSYbm8E p+X3ePDepMg6nPwOPdhZfeN/V4ssdP3MowcXEHV6KzdH1sHIm4RMYCY5mvZ8L6oht7+S 912g== X-Gm-Message-State: APjAAAVSz1EbeWPU8P0faH0mtUf86IiINMqmTVVHOeSxjvzZNR12MXdM nYTkEZFeEcCrKyrjJIh6DqQx1cKCwcr3HMo5qok= X-Received: by 2002:a19:3805:: with SMTP id f5mr3768257lfa.173.1570134082446; Thu, 03 Oct 2019 13:21:22 -0700 (PDT) MIME-Version: 1.0 References: <20190930112636.vx2qxo4hdysvxibl@willie-the-truck> <20190930121803.n34i63scet2ec7ll@willie-the-truck> <20191001092823.z4zhlbwvtwnlotwc@willie-the-truck> <20191001170142.x66orounxuln7zs3@willie-the-truck> <20191001175512.GK25745@shell.armlinux.org.uk> <20191001181438.GL25745@shell.armlinux.org.uk> In-Reply-To: From: Miguel Ojeda Date: Thu, 3 Oct 2019 22:21:11 +0200 Message-ID: Subject: Re: [PATCH] compiler: enable CONFIG_OPTIMIZE_INLINING forcibly To: Linus Torvalds Cc: Masahiro Yamada , Geert Uytterhoeven , Nick Desaulniers , Russell King - ARM Linux admin , Will Deacon , Nicolas Saenz Julienne , Andrew Morton , Ingo Molnar , Borislav Petkov , linux-arch , LKML , Catalin Marinas , Stefan Wahren , Kees Cook , Arnd Bergmann , clang-built-linux Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 3, 2019 at 7:29 PM Linus Torvalds wrote: > > On Thu, Oct 3, 2019 at 10:24 AM Masahiro Yamada > wrote: > > > > I just want to annotate __always_inline for the case > > "2. code that if not inlined is somehow not correct." > > Oh, I support that entirely - if only for documentation. > > But I do *not* support the dismissal of the architecture maintainers > concerns about "does it work?" and apparently known compiler bugs. > > > Again, not saying "use a macro". > > Other people did, though. > > And there seemed to be little balancing of the pain vs the gain. The > gain really isn't that obvious. If the code shrinks by a couple of kB, > is that good or bad? Maybe it is smaller, but is it _better_? I think both positions that people have shown are important to take into account. We should minimize our usage of macros wherever possible and certainly not write new ones when another solution is available. But we should *also* minimize our dependence on code that "must-be-inlined" to work as much as possible. In particular, I think we should allow to use __always_inline only if it doesn't work otherwise, as an alternative before trying the next worst solution (macros). And avoid using only "inline" when we actually require inlining, of course. And the reasoning for each usage of __always_inline should have a comment (be it "bad codegen", "performance tanks without it", "compiler X <= 4.2 refuses to compile"...). Which is also useful for compiler folks to grep for cases to improve/fix in their compiler! Cheers, Miguel