From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C0ABC32792 for ; Mon, 30 Sep 2019 22:34:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1BB0720842 for ; Mon, 30 Sep 2019 22:34:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MOWTHPUw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728176AbfI3Wey (ORCPT ); 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-Google-Smtp-Source: APXvYqyOU2bwSPdSL51Jh7RdzyoNXLxhELPpgkbg72EzzJZ/2dNcZv/B/p8mtSppYe8kSal5ZVqB7ESgT0GvDuiU08g= 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