Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp7530927ybn; Mon, 30 Sep 2019 15:37:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqxHULwrSDvVHMIgtGbhD634PQrTdWu2Zdb1E8RLdBGWlz8NNUiIRhWGcQ2I4eL7ETgj0YmW X-Received: by 2002:a17:906:4bc3:: with SMTP id x3mr21102420ejv.200.1569883052439; Mon, 30 Sep 2019 15:37:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569883052; cv=none; d=google.com; s=arc-20160816; b=g0w5BQbjqiOOH9voWIwvivxvXdmJFbhZ4xnVkjA2kHtCW94EY613GdMewsWL3xFxVS bpwZkwr9FsYv+PkPnzfzQYjYsltI5o5uozhM2uM5Pj6aJ7UPk+CORSJzQ0DtHK8F51zE rQyWECvdSYjsLLqz9EeIu0g2MZMx1a9eJQy/PoUjPxe9zlbp2FujQSeIUoHM5cT5QRNQ cWUXpbI/Uaw+zU1bUurJjIHGadCoWkuk8NzrArDnBOWxaHQ0f0CrvrQwwQGX+i1gqjxl MAMDgVNGW+A+Khg5dXoY/qOlT4fddxQAzCXXpSBW7ehmL6mb2zxqr+nJA1jHRyZizpSB 89zg== 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=7SR5SJpCZzCR2HUyKgols4Ma/MTXm0Tu30NRGBJBmLQ=; b=BiUHN+jZMn65AMEzGnlZNh3skDZfsyK0RvCHUQOBAfnKOdPtXItNkp79QX+WBUQxkY WIC/aKmKE3RiWzXNwQh85iG9HJhIChzjmqc3oBYkzUMjYwQtvthT+PvUxNkAmty0y6bB 1O44oP5LrFCOcgA6t9aPylZWYYstKsdtBis2bAwT52qCXSzIWNQDgPN5JxWk3Z8gO6Lf 9j2Z/idPDCh6APSthqaktbPLdOoXR96bnz5tbwm6oXyMtPKiHCAzNd+rD1OaG08HVgWq zf9BE3xpqWGmTMhetb83lLiRMvQn/XLmwvAaAODctBMW0isr0d0/fuhDOpMtTC+WGqDV N4NQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=MOWTHPUw; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d27si8450165ede.381.2019.09.30.15.37.07; Mon, 30 Sep 2019 15:37:32 -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=@google.com header.s=20161025 header.b=MOWTHPUw; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727469AbfI3Wey (ORCPT + 99 others); Mon, 30 Sep 2019 18:34:54 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:44516 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726350AbfI3Wey (ORCPT ); Mon, 30 Sep 2019 18:34:54 -0400 Received: by mail-pg1-f193.google.com with SMTP id i14so8147915pgt.11 for ; Mon, 30 Sep 2019 15:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7SR5SJpCZzCR2HUyKgols4Ma/MTXm0Tu30NRGBJBmLQ=; b=MOWTHPUwU1iS50Z3VFZA5DFevN71k70iB6IqofUavf/x1Nw+kv1n0f0Sq5oAZEzLvL xLQFdHuY2ewoREYA3vaIqrKdhMxDxcKTmjl9JS5mLDb//GKRO4pR9pr0tGSdFwURX/Hm q+rCUWqufGVzOq/ajZ4+ysaFaZF39LNfK6RxkybZ7Ld/DFxDtmSlJNzHEIv/BZhE+44m WV6trAVqy1zOmVuGaejXWaRtNbSI1LWY2Y1QUafxdmQifE14+Vo/0IWblPjFVpw8zYyZ UUfsJZRE54IiOF4YqjuO/qBjMN2RhDYUOixGN1CN8FS834d1pmqTq7UWdEHpavKTXIiq oSyw== 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=7SR5SJpCZzCR2HUyKgols4Ma/MTXm0Tu30NRGBJBmLQ=; b=CPuITodaiu0EYzvjmEr2mNprtdAfbohdhHdCgxiYDeYOlTroa8BgsVT6B2fwpPFhLP 4lYFEJ0Q+5eeZpAP77mUv2CdBuN4SScSY9i97yefDgss10KxJAcsKQMO7FmKeqiCY/nq lp1aSlGphcWFm3utcU/tdFfcePLsBAz/TocUIQ05B9WoRmnneHfB1BgaZ8X2sxWl9swP WjfjNVGMaORPoZIJUXHBL6U1lZyw60LucCX2OsP0u566P8r8oWi5MO1N07gFn51c4MKz /dlrBo0kpEcVvIIvqBs2scXVQe7nwwUIWvuwiIAP9NLyfu5pRxxvG2eE9FWc5R2QFk9D odAw== X-Gm-Message-State: APjAAAXxFT9yUz+eKNn0U33cNadKZXnpzTxdqA5Q4Czkasd5XtOupd4d zn9HMdJT0XSNO4GOT9H87D3dCY2hT1sWiF1EtSqWcA== X-Received: by 2002:a17:90a:178d:: with SMTP id q13mr1777052pja.134.1569882893154; Mon, 30 Sep 2019 15:34:53 -0700 (PDT) MIME-Version: 1.0 References: <20190830034304.24259-1-yamada.masahiro@socionext.com> <20190930112636.vx2qxo4hdysvxibl@willie-the-truck> <20190930121803.n34i63scet2ec7ll@willie-the-truck> In-Reply-To: From: Nick Desaulniers Date: Mon, 30 Sep 2019 15:34:41 -0700 Message-ID: Subject: Re: [PATCH] compiler: enable CONFIG_OPTIMIZE_INLINING forcibly To: Miguel Ojeda Cc: Will Deacon , Masahiro Yamada , Linus Torvalds , Nicolas Saenz Julienne , Andrew Morton , Ingo Molnar , Borislav Petkov , linux-arch , LKML , Catalin Marinas , Russell King , Stefan Wahren , Kees Cook 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 Mon, Sep 30, 2019 at 3:08 PM Miguel Ojeda wrote: > > On Mon, Sep 30, 2019 at 11:50 PM Nick Desaulniers > wrote: > > > > So __attribute__((always_inline)) doesn't guarantee that code will be > > inlined. [...] inline and __attribute__((always_inline)) > > are a heuristic laden mess and should not be relied upon. > > Small note: in GCC, __attribute__((always_inline)) is documented as > actually guaranteeing to either inline or error otherwise (although > see the remark for indirect calls): > > "Failure to inline such a function is diagnosed as an error. Note Not an error, but a warning at least: https://godbolt.org/z/_V5im1. That's interesting, so it has multiple semantics, because it's also documented to inline even when no optimizations are specified. So when someone uses __attribute__((always_inline)) without a comment, it's not clear whether they mean for there to be a warning when this is not inlined, or for it to be inlined at -O0 (guess not for the kernel), or both. If the kernel wants to enforce the former, why not set `-Werror=attributes`? Maybe that warning is too broad? Seems like a recipe for subtly broken code found at runtime, when we'd rather have stronger compile time guarantees. > that if such a function is called indirectly the compiler may or may > not inline it depending on optimization level and a failure to inline > an indirect call may or may not be diagnosed." > > As for LLVM/Clang, no idea, since it does not say anything about it in > the docs -- but from what you say, it is a weaker guarantee. Filed https://bugs.llvm.org/show_bug.cgi?id=43517 -- Thanks, ~Nick Desaulniers