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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 7FBCFC433E0 for ; Mon, 6 Jul 2020 19:44:06 +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 4E02920675 for ; Mon, 6 Jul 2020 19:44:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="bySdCY1m"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="lh3vxVKB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E02920675 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:Reply-To:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=RDIBpSFj4+hzgpHShXU/51WCpL+zkAkkfg0dLZo54cQ=; b=bySdCY1mYZbErB0wQQXXDMtRLo S4nEeRGU82aqhL69MZtHGMQKD1lBzHVlE7DrwRrIknbB22FIcGBXTJG/ovaoJ8S0wavitA6ZmD058 XWYNFwnYbYVwGhZFc4fMg1WoEaMCG0YZxaQyh6LMlQKlBLoCoZPcSwD1cPX5PjZHdJG/ct6FM2+qD mkzmJrmh0GTwGTMoTqCYJamIgCz4YQg3GGvp1HeG8OLIBfxqPoCXXwmEzAdc258CLBddjxHlMBxzK Yq47AP3YiW8dbrrY+CDIKNY7gxs0SyucIltK6G6Mm+CsbG+YEC6eYsvaw7VycqfOZN3Wbd+cUwGeE bMVH8u3A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsX0i-0002lW-NZ; Mon, 06 Jul 2020 19:42:40 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsX0f-0002kL-Se for linux-arm-kernel@lists.infradead.org; Mon, 06 Jul 2020 19:42:38 +0000 Received: from paulmck-ThinkPad-P72.home (50-39-111-31.bvtn.or.frontiernet.net [50.39.111.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2E08120675; Mon, 6 Jul 2020 19:42:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594064557; bh=gq8OONsZv2DL9Wl2RlB9KVkvm70QuCx2mh8QqqjtMbI=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=lh3vxVKBCu2a1xT47mTYziII5iB0/8GAkDAt71DAfoKVDSx6FVqCJSq59QVsEGSnP Q60Pvq90qvfChKmNKQJkCuTpUGESomfnWfhOoPesvmXeSdfBqBsiWX1GemxQCisw41 x0SD+lBBhKrCWfQ4CGoMu0RtilR1klMo8qmHvImM= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id 181CE3522637; Mon, 6 Jul 2020 12:42:37 -0700 (PDT) Date: Mon, 6 Jul 2020 12:42:37 -0700 From: "Paul E. McKenney" To: Marco Elver Subject: Re: [PATCH 18/18] arm64: lto: Strengthen READ_ONCE() to acquire when CLANG_LTO=y Message-ID: <20200706194237.GF9247@paulmck-ThinkPad-P72> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200706_154238_102802_49FAD4CA X-CRM114-Status: GOOD ( 30.26 ) 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: , Reply-To: paulmck@kernel.org Cc: Mark Rutland , "Michael S. Tsirkin" , Peter Zijlstra , Catalin Marinas , Jason Wang , virtualization@lists.linux-foundation.org, Will Deacon , Alan Stern , Sami Tolvanen , Matt Turner , Android Kernel Team , Dave Martin , Kees Cook , Arnd Bergmann , 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, Jul 06, 2020 at 09:23:26PM +0200, Marco Elver wrote: > 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. :-) Anything along these lines would be very welcome!!! Thanx, Paul _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel