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.0 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,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 9B6FEC433DF for ; Wed, 24 Jun 2020 21:33:25 +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 6A9A4207FC for ; Wed, 24 Jun 2020 21:33:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="2lA6F+tu"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="YLhBzo5t" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6A9A4207FC 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: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=4h91RGL0/b0WDuZyugmzROYwv92kFGv/soYq+4rPnp8=; b=2lA6F+tuZPvIUbZ7zPbCwnxyT 05WqBLLDWqHmTeyvLenjpQjcWRG///yAbLCPH/WRASs9jUJ19OwajKCsRVwRfT4RAJagnZdHOiwfN +sHR9cfmp9Vt920mzh3acT1pZ1q39txitjzMGEzRrhnE2GHRZrYTAoqoZnUwf84cRDklwLYvmrRc7 wO/8UfWFUUqkyY1Wjbib/x0x1chGrNzgKm2dT8ovKjxlwo3uOY7Tg8mxq2/Cd7/pJbzvCw53DVtLS vPt7oDlRxysiURxGW6MtMJGQmuUnsV6tqGmHTMffQEgWH8clgy4dBjTCCtE5LLHn5TkzSmkkwVK6f a4bH0J3BQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1joCzp-0008IX-I8; Wed, 24 Jun 2020 21:31:53 +0000 Received: from mail-pl1-x644.google.com ([2607:f8b0:4864:20::644]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1joCzm-0008H4-Bo for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2020 21:31:51 +0000 Received: by mail-pl1-x644.google.com with SMTP id s14so1660372plq.6 for ; Wed, 24 Jun 2020 14:31:50 -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=oeZYP2K14l8wy15C+mHJ7IGJGj+bMsdiaVhcvV254wo=; b=YLhBzo5tLLnGs0t6TdhnFSz7LC+dIOGSdyR2PzbiJ5sbNeH/OqOlpGPE843RDUqPyB xcP72I6Wr3gEeg8vpHpVkU6u63LLrd63P+x1ZZGXfe69+AWJdANZ6EXt2a9Wp3ONoSX+ IYQFe9nK3k7itVIzd+Ql+LZ3lDH+ctkvhSsUBvpMOUjNf93JbToJ7w7Jl9+ej3WyaGi0 t64ZoJLPWNph8t4rfm6P3KDNWB+A/4Ny+h52bYBhzjkl8jF/deowywj6kuu84Svv0pXL Tt9UDtDNXClNBGQZGornTX62JX0NBkg8bcnSbq3QZ1eCahNDu3bRnftlUijmcZVfck9j lPdg== 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=oeZYP2K14l8wy15C+mHJ7IGJGj+bMsdiaVhcvV254wo=; b=joTfk5Rhx2ysOgcKSz5Me5OSTxHRCzB5Ye8eEXNXXbfMtwc/lH/JHdUjMzdAL8/2ya vlstwrrzQ708lmfR6emRs8uJDdfQnUF0RCq3ALFNEtzZXPkVLRJ4efM6WmwgmEAsyQiE 4V+lrqr35iX+2gR4qHDd8z4jHwl6GbXw2LADzDkiJiwaiRU4J4x2aUoA6Wf1fSSwns5+ y2/Kz3aMqHNJeaUJxk2NelAX+tqSILHHScXaQmsomckIelmynOmTi1GFtzGUM3MoEMCE rhB14IB1Ls6FDS+hCB3Awq09PsVr29XAnsBY5qRDY6JxN68rrLf32NIPYFhkZuQh3dRU EbSQ== X-Gm-Message-State: AOAM5339t89riphqRJIuqBO6mqWydDlQinaQqTCFN3r3i36pyzR3SSHq yR70p17dRdx8aFskQlwibrZEr5CrKjEPKZwSQB7Erw== X-Google-Smtp-Source: ABdhPJz+HM0notouaxjjmVfRuFFbkI9iWq5lvgoF8vO75RohUtNuXeLwq0dwZGEXHBIiKBXeihMyXNtyRUAlF/ihVkc= X-Received: by 2002:a17:90a:1e:: with SMTP id 30mr28248270pja.25.1593034308056; Wed, 24 Jun 2020 14:31:48 -0700 (PDT) MIME-Version: 1.0 References: <20200624203200.78870-1-samitolvanen@google.com> <20200624211540.GS4817@hirez.programming.kicks-ass.net> In-Reply-To: <20200624211540.GS4817@hirez.programming.kicks-ass.net> From: Nick Desaulniers Date: Wed, 24 Jun 2020 14:31:36 -0700 Message-ID: Subject: Re: [PATCH 00/22] add support for Clang LTO To: Peter Zijlstra 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 , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , Kees Cook , "Paul E. McKenney" , Kernel Hardening , Greg Kroah-Hartman , Masahiro Yamada , Linux Kbuild mailing list , LKML , clang-built-linux , Sami Tolvanen , linux-pci@vger.kernel.org, Will Deacon , Linux ARM 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, Jun 24, 2020 at 2:15 PM Peter Zijlstra wrote: > > On Wed, Jun 24, 2020 at 01:31:38PM -0700, 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's > > Pixel devices have shipped with LTO+CFI kernels 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 first objtool patch in the series is already in linux-next, > > but as it's needed with LTO, I'm including it also here to make testing > > easier. > > I'm very sad that yet again, memory ordering isn't addressed. LTO vastly > increases the range of the optimizer to wreck things. Hi Peter, could you expand on the issue for the folks on the thread? I'm happy to try to hack something up in LLVM if we check that X does or does not happen; maybe we can even come up with some concrete test cases that can be added to LLVM's codebase? -- Thanks, ~Nick Desaulniers _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel