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=-0.8 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 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 461DAC433DF for ; Mon, 6 Jul 2020 19:25:08 +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 11C04206B6 for ; Mon, 6 Jul 2020 19:25:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Ze8zl0FT"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="kktLS6II" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11C04206B6 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=Z6/NkXgsJ4O97cDaLl5/cHcPRLd9hn+DoXXCh+bqDcc=; b=Ze8zl0FTBh9iPDxz467COjl9q 1Eht7oWbDiRHbaA1d6e1HKJQiI7tBKoS0orqQfuJUlMDi+sJEAauspIRd4cguxlIVC21Icg8eqN1n OC/lZwTmzXT2yxV3JlswLnDlkNebRDCeNLOxo0kE6Fjuzw+cGQT7jMDUcOcSPo33yZPM3kN7NMt2z sJ6qPpe7bfpw9JDasNad2YpKoGMKvaY45Y7vY2vwkyhwlzSKqvXoWHvQ28zeu0Mb4r8oOs35qgQud 5oeWl8ELHWzuCN9oY98MhPt5mHqG2hAWnz6Dl7ChyNyu0+vUdp/KT+P83P/E0hMFXXMiosdmHEUuy S5zBxFgpg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsWiP-0000kE-SP; Mon, 06 Jul 2020 19:23:45 +0000 Received: from mail-oi1-x241.google.com ([2607:f8b0:4864:20::241]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsWiM-0000iA-He for linux-arm-kernel@lists.infradead.org; Mon, 06 Jul 2020 19:23:43 +0000 Received: by mail-oi1-x241.google.com with SMTP id l63so31488995oih.13 for ; Mon, 06 Jul 2020 12:23:39 -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=7rVviAD5LzlDObQk5Wo1OIPXX0O0i14V8Y9kck3sGsA=; b=kktLS6II7R90NPohUeMToqXFTW9/KTTxKsvR9z6CQOtuYiA+UR1ubootJAzBto7yuJ AbRvCe66+Tt8q+e7CaqjBO/+BqOggtYUZd94QOOMy3P6tdZbgMFUX2kKcMpO2rBMAiQV 5P3zf0HiGPY4b0db3+VWxD2tkv5CY7XEZlXVtx3qjIKDMVpq9AFvxZ2W+5yyNFj3mHWq KzP6T0h5FK7Z0GIwe04akbYFIG6ZBAT1RiOTM/kh1P3VhD+BMpi4H6OFelIwdriMLqyW CZAxAVAwkoGHY7q2qlbqV+rOUxl6ESs/jNfXniEGzfMGnS5htYM2u2lyMprNvZeKvtN3 U91Q== 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=7rVviAD5LzlDObQk5Wo1OIPXX0O0i14V8Y9kck3sGsA=; b=MboBKZxg+5tnAYf+RdIKCONerwi/8Q4YMpG0XU4mu5Di4YsoD9eWOJ4lhJWp6OzGKO 6SyugshhTirmSVPp+bquQqvXBMFDnmlwGYUkhAo0yinrqLgg0Wt4Ys/351kPwdhQpFQ9 2SF8dTmVG5bCELIdfhSgb/f5jWZY1XFct21fPFEMM9CQ7n+Oftbp3qsdxFWERbkCEArN zLfmc3ZJ2FDJasRmWiuppUJiAyvrdQJ9SwcBjTWbziShxT5f2AK3JrYWXD1OlcenkXHd A4C55M1EdhDgpeJDG6Hd+r6NDdMk65XhkHk5Auar8AV5p1UKm3vjKTY98Eaw/3JUehIY ImRA== X-Gm-Message-State: AOAM533VnE7zFZRE1DpGmlxZvuaecX2htYx8R/YlScXGs1LYrSARiowc 4HvcW3T3eQX0b3wJ9KftGalufXjyc6qS8rH87K+bXw== X-Google-Smtp-Source: ABdhPJzDA9ukIWYEyzFrrnOq5gnL5jJJGkB5l/SHZwqTzTGYEqqNcILaV0tH8QfdlHzy2n6eGpcpSpiSxjL7cUQQYHg= X-Received: by 2002:aca:5007:: with SMTP id e7mr682320oib.70.1594063417791; Mon, 06 Jul 2020 12:23:37 -0700 (PDT) MIME-Version: 1.0 References: <20200630173734.14057-1-will@kernel.org> <20200630173734.14057-19-will@kernel.org> <20200701170722.4rte5ssnmrn2uqzg@bakewell.cambridge.arm.com> <20200702072301.GA15963@willie-the-truck> <20200706160023.GB10992@arm.com> <20200706183542.GB23766@willie-the-truck> In-Reply-To: <20200706183542.GB23766@willie-the-truck> From: Marco Elver Date: Mon, 6 Jul 2020 21:23:26 +0200 Message-ID: Subject: Re: [PATCH 18/18] arm64: lto: Strengthen READ_ONCE() to acquire when CLANG_LTO=y To: Will Deacon X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200706_152342_632651_7756F9F7 X-CRM114-Status: GOOD ( 24.78 ) 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: Mark Rutland , "Michael S. Tsirkin" , Peter Zijlstra , Catalin Marinas , Jason Wang , virtualization@lists.linux-foundation.org, Arnd Bergmann , Alan Stern , Sami Tolvanen , Matt Turner , Android Kernel Team , Dave Martin , Kees Cook , "Paul E. McKenney" , Boqun Feng , Josh Triplett , Ivan Kokshaysky , Linux ARM , Richard Henderson , Nick Desaulniers , LKML , linux-alpha@vger.kernel.org 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 Mon, 6 Jul 2020 at 20:35, Will Deacon wrote: > On Mon, Jul 06, 2020 at 05:00:23PM +0100, Dave Martin wrote: > > On Thu, Jul 02, 2020 at 08:23:02AM +0100, Will Deacon wrote: > > > On Wed, Jul 01, 2020 at 06:07:25PM +0100, Dave P Martin wrote: > > > > Also, can you illustrate code that can only be unsafe with Clang LTO? > > > > > > I don't have a concrete example, but it's an ongoing concern over on the LTO > > > thread [1], so I cooked this to show one way we could deal with it. The main > > > concern is that the whole-program optimisations enabled by LTO may allow the > > > compiler to enumerate possible values for a pointer at link time and replace > > > an address dependency between two loads with a control dependency instead, > > > defeating the dependency ordering within the CPU. > > > > Why can't that happen without LTO? > > It could, but I'd argue that it's considerably less likely because there > is less information available to the compiler to perform these sorts of > optimisations. It also doesn't appear to be happening in practice. > > The current state of affairs is that, if/when we catch the compiler > performing harmful optimistations, we look for a way to disable them. > However, there are good reasons to enable LTO, so this is one way to > do that without having to worry about the potential impact on dependency > ordering. If it's of any help, I'll see if we can implement that warning in LLVM if data dependencies somehow disappear (although I don't have any cycles to pursue right now myself). Until then, short of manual inspection or encountering a bug in the wild, there is no proof any of this happens or doesn't happen. Also, as some anecdotal evidence it's extremely unlikely, even with LTO: looking at the passes that LLVM runs, there are a number of passes that seem to want to eliminate basic blocks, thereby getting rid of branches. Intuitively, it makes sense, because branches are expensive on most architectures (for GPU targets, I think it tries even harder to get rid of branches). If we extend our reasoning and assumptions of LTO's aggressiveness in that direction, we might actually end up with fewer branches. That might be beneficial for the data dependencies we worry about (but not so much for control dependencies we want to keep). Still, no point in speculating (no pun intended) until we have hard data what actually happens. :-) Thanks, -- Marco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel