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=-1.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,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 5FE29C43461 for ; Tue, 8 Sep 2020 23:48:24 +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 05208206DB for ; Tue, 8 Sep 2020 23:48:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="w3zjYPi9"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="o7AAPg2t" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 05208206DB Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com 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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=YWO+WvYGtf0LErWY5JUywcnm8XVMt/k+oRMD6+IZLKA=; b=w3zjYPi9WIXQpph4LyxK62wmf qf1c7GcZ7S8I49MqZvmpW1E0g+2twgcCF670LsmlkRBEK4Gdd7bxSORwwb4ZYmHCTohbFqyQc2ik8 i2uuFqTdnZDiigM5pPAPGrBvB8Ql2dySSNXpf/FhYrjyCEeuTSQ0455e7+pp58IWHnGYwmGDdQy6E 14MKqKgtBYSLIwjncDCb6499xkNKKk1KwORZPPSzwpkzbuV3WnIKfXTvtECKIkEZO+iMoCXyytNVD 0i0HLhAAwl6p6CyNGcGeC4yYVxJ7/DEtJXTwEDJrrDgclF1zfZZZ8L4JDEAIl3GDk6pfROSOMpNfQ EGT6HV0Gw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFnKB-0000OB-N3; Tue, 08 Sep 2020 23:46:55 +0000 Received: from mail-pg1-x542.google.com ([2607:f8b0:4864:20::542]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFnK8-0000NH-Ni for linux-arm-kernel@lists.infradead.org; Tue, 08 Sep 2020 23:46:53 +0000 Received: by mail-pg1-x542.google.com with SMTP id e33so706882pgm.0 for ; Tue, 08 Sep 2020 16:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=z8KgGGQx1h7YczMCEetfx/jb92oxBiLV/4DApZXEdSc=; b=o7AAPg2tGIBeoDCy+SKZSPrMh90LWzBsQz7vIgRgf0gXKcazYi7dMUuiHS6pkeEhe3 72U8LTqKCD+Y0nvZWHnSCPgKx22WrkcnXsI1zBTHp65y4SK7sUDb96k8i08E7N1I3ndK MAbE+qSMIBBIRaP4TaKmNwhLB/bhB54qsZiAh3Ur4seHsvyrTB8t5y34VNrcKVW/C66L l7cjL+k9FUiFppFSh3huLQBHCcZYt8E1otUR46Y0GfuzwzhPLhut+2yC5pR2SQvSs0VL ilFTrWMA4JBjFg121/n2oGTyDANdfOuIpPL/4ZyE02D71+D1zpI6L2df8XB6haMHzveL 5RSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=z8KgGGQx1h7YczMCEetfx/jb92oxBiLV/4DApZXEdSc=; b=MsDuhCZ3S6wD9G/W59tgpaKT6bbycyTKiXFgOFwAR52GadYTzP57TSoQiUvIgyVwoP 5gRCsrOz9ZCxKyb4nte6pkOZtSstgiijKxUE7ky3DG0feK9bPXWQxE5vwq+jgbU/pADd 29SQd9nG7t95Qxdj2OxnCrswmGjNNQ4cF4eFjdjMo3tNZDzJv7uKVyVdUrpldMYXpL6E 3FaXbPn0dzM/91lJ/0hrvpggb667AqsfqxveoWDbgLmm+f24zyDATGGubo262LBsBYjX RrTebrlcEYXp9olG3VbHSwuPk6DZTKWvH/g821FaXs4ZqWKJUX69fpIp4tNMnOxCY2bl ut3A== X-Gm-Message-State: AOAM533OPTHD4LMzMd83Bra60gGY4iHxgMr02rgeGfDJjqe8yYGOKOoe fL8bSxMbQDIwsvlpxsxqXTzlOQ== X-Google-Smtp-Source: ABdhPJyPXjsg2EPOqZVE0HrEMh1e+YhXcjhHaIFb+FoC7uPh34ggtt3CwAG5NZI9KmvOFhjBQ3KjBw== X-Received: by 2002:a63:4664:: with SMTP id v36mr859465pgk.194.1599608809917; Tue, 08 Sep 2020 16:46:49 -0700 (PDT) Received: from google.com ([2620:15c:201:2:f693:9fff:fef4:1b6d]) by smtp.gmail.com with ESMTPSA id n67sm332121pgn.14.2020.09.08.16.46.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2020 16:46:49 -0700 (PDT) Date: Tue, 8 Sep 2020 16:46:43 -0700 From: Sami Tolvanen To: Masahiro Yamada Subject: Re: [PATCH v2 00/28] Add support for Clang LTO Message-ID: <20200908234643.GF1060586@google.com> References: <20200624203200.78870-1-samitolvanen@google.com> <20200903203053.3411268-1-samitolvanen@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200908_194652_797989_FBB504E3 X-CRM114-Status: GOOD ( 35.07 ) 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 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. This is why we need global wrappers for initcalls, for example, to have stable symbol names. Sami _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel