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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 847E9C433E2 for ; Thu, 10 Sep 2020 01:20:45 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C3B9F2078E for ; Thu, 10 Sep 2020 01:20:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="F3WqBP6g"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=nifty.com header.i=@nifty.com header.b="WGjr5LVs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C3B9F2078E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=fexAItF6zQmuKwgqEX4pVNv9HhSHvJTepdLW2x+AN+4=; b=F3WqBP6gjh4uhMhqoQL2EpTyw TSWA953mNXN60r7H5boqVx+yTsuQS6p+xHejFiCAt1SyueW/H7IbwbzVs0EFKLHSTNRg/mCA9/gu4 nZrNRSh5Gi3JfXXPTJ7Kt63t5pvwaqh4gPPInI7MSLA1Qyg6fI/24hRScCXIu/A/8u1gmO7N1AXwk 5G0UPfvurC1WS/QcDrff6+cGVOmPEzgx+DbJnBJUlXs5fqtkrK0YJsOCkrCf0mZ4ZvrCAx16Ija1N cem0xdDmqP00mlh02AUfG027CeHoGie2ixZtTLgdG6hC7KFvYsv7TirlAIIzTeRNVXhZII+mhX414 z+x2LPnng==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGBEs-0005Lb-ND; Thu, 10 Sep 2020 01:19:02 +0000 Received: from conssluserg-03.nifty.com ([210.131.2.82]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGBEo-0005KL-Kb for linux-arm-kernel@lists.infradead.org; Thu, 10 Sep 2020 01:19:00 +0000 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) (authenticated) by conssluserg-03.nifty.com with ESMTP id 08A1Ihda006883 for ; Thu, 10 Sep 2020 10:18:43 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-03.nifty.com 08A1Ihda006883 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1599700724; bh=x2qUAAqVWiePSrCzfI1IEP4eafAB9yee8r8ckQho/u8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WGjr5LVsquWsgfjbUw8zsVNV+eA8G4HhcuX7mJ53BwE1QXEJLWsiBBR8lguwcOerT d71o9nfLv7ija30NHqQedE2CfJD68H7zHtYLQdmNLNYavfgBOdGEVAam0QzLlPx5Q2 6EJvPCcYrNNyDZNKB0TNqWiS2LuxTF6IL0ttSnkDcBELKjgx7TEBTYnWbGAc/tZbYZ ZMn59+M37cpTDQVmqeXbYfFIZ/VUmlVU6FP4rP8nFvJoOjs3HFc/LbGKo4YdWIQOK6 KSbHxjj2F61Imz4LpNo5mWBjeXerF0bjYZRmNxbsHsNpkA4wxyCBw0p6bFOn5d+i5j eYvVVaetEFYKg== X-Nifty-SrcIP: [209.85.215.177] Received: by mail-pg1-f177.google.com with SMTP id v15so3337587pgh.6 for ; Wed, 09 Sep 2020 18:18:43 -0700 (PDT) X-Gm-Message-State: AOAM530wC3D93nVWWMzPnCEYcel1vOewf3iUSJUJ9UcCYLpYgWJGIPPS Fkn1SEKiI3jJpBQMJpMYgrT2VfO9k/tiCoNwYQo= X-Google-Smtp-Source: ABdhPJw3+uiV59rG6EDJ8QWqM7TRK95TtkCpF/iAWICblIOjIFopt/zBNTTyCv+Bm880c1rm+ZI8WQaujb2+mHAsSEI= X-Received: by 2002:a63:f546:: with SMTP id e6mr2466312pgk.7.1599700722672; Wed, 09 Sep 2020 18:18:42 -0700 (PDT) MIME-Version: 1.0 References: <20200624203200.78870-1-samitolvanen@google.com> <20200903203053.3411268-1-samitolvanen@google.com> <20200908234643.GF1060586@google.com> In-Reply-To: <20200908234643.GF1060586@google.com> From: Masahiro Yamada Date: Thu, 10 Sep 2020 10:18:05 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 00/28] Add support for Clang LTO To: Sami Tolvanen X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200909_211859_046999_A8B8FB5E X-CRM114-Status: GOOD ( 40.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch , X86 ML , Kees Cook , "Paul E. McKenney" , Kernel Hardening , Peter Zijlstra , Greg Kroah-Hartman , Linux Kbuild mailing list , Nick Desaulniers , Linux Kernel Mailing List , Steven Rostedt , clang-built-linux , linux-pci@vger.kernel.org, Will Deacon , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Sep 9, 2020 at 8:46 AM Sami Tolvanen wrote: > > On Sun, Sep 06, 2020 at 09:24:38AM +0900, Masahiro Yamada wrote: > > On Fri, Sep 4, 2020 at 5:30 AM Sami Tolvanen wrote: > > > > > > This patch series adds support for building x86_64 and arm64 kernels > > > with Clang's Link Time Optimization (LTO). > > > > > > In addition to performance, the primary motivation for LTO is > > > to allow Clang's Control-Flow Integrity (CFI) to be used in the > > > kernel. Google has shipped millions of Pixel devices running three > > > major kernel versions with LTO+CFI since 2018. > > > > > > Most of the patches are build system changes for handling LLVM > > > bitcode, which Clang produces with LTO instead of ELF object files, > > > postponing ELF processing until a later stage, and ensuring initcall > > > ordering. > > > > > > Note that patches 1-4 are not directly related to LTO, but are > > > needed to compile LTO kernels with ToT Clang, so I'm including them > > > in the series for your convenience: > > > > > > - Patches 1-3 are required for building the kernel with ToT Clang, > > > and IAS, and patch 4 is needed to build allmodconfig with LTO. > > > > > > - Patches 3-4 are already in linux-next, but not yet in 5.9-rc. > > > > > > > > > I still do not understand how this patch set works. > > (only me?) > > > > Please let me ask fundamental questions. > > > > > > > > I applied this series on top of Linus' tree, > > and compiled for ARCH=arm64. > > > > I compared the kernel size with/without LTO. > > > > > > > > [1] No LTO (arm64 defconfig, CONFIG_LTO_NONE) > > > > $ llvm-size vmlinux > > text data bss dec hex filename > > 15848692 10099449 493060 26441201 19375f1 vmlinux > > > > > > > > [2] Clang LTO (arm64 defconfig + CONFIG_LTO_CLANG) > > > > $ llvm-size vmlinux > > text data bss dec hex filename > > 15906864 10197445 490804 26595113 195cf29 vmlinux > > > > > > I compared the size of raw binary, arch/arm64/boot/Image. > > Its size increased too. > > > > > > > > So, in my experiment, enabling CONFIG_LTO_CLANG > > increases the kernel size. > > Is this correct? > > Yes. LTO does produce larger binaries, mostly due to function > inlining between translation units, I believe. The compiler people > can probably give you a more detailed answer here. Without -mllvm > -import-instr-limit, the binaries would be even larger. > > > One more thing, could you teach me > > how Clang LTO optimizes the code against > > relocatable objects? > > > > > > > > When I learned Clang LTO first, I read this document: > > https://llvm.org/docs/LinkTimeOptimization.html > > > > It is easy to confirm the final executable > > does not contain foo2, foo3... > > > > > > > > In contrast to userspace programs, > > kernel modules are basically relocatable objects. > > > > Does Clang drop unused symbols from relocatable objects? > > If so, how? > > I don't think the compiler can legally drop global symbols from > relocatable objects, but it can rename and possibly even drop static > functions. Compilers can drop static functions without LTO. Rather, it is a compiler warning (-Wunused-function), so the code should be cleaned up. > This is why we need global wrappers for initcalls, for > example, to have stable symbol names. > > Sami At first, I thought the motivation of LTO was to remove unused global symbols, and to perform further optimization. It is true for userspace programs. In fact, the example of https://llvm.org/docs/LinkTimeOptimization.html produces a smaller binary. In contrast, this patch set produces a bigger kernel because LTO cannot remove any unused symbol. So, I do not understand what the benefit is. Is inlining beneficial? I am not sure. Documentation/process/coding-style.rst "15) The inline disease" mentions that inlining is not always a good thing. As a whole, I still do not understand the motivation of this patch set. -- Best Regards Masahiro Yamada _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel