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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 75343C433FF for ; Tue, 30 Jul 2019 19:37:30 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 B95A920659 for ; Tue, 30 Jul 2019 19:37:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B95A920659 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 45ymzW1BGkzDqXm for ; Wed, 31 Jul 2019 05:37:27 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=permerror (mailfrom) smtp.mailfrom=kernel.crashing.org (client-ip=63.228.1.57; helo=gate.crashing.org; envelope-from=segher@kernel.crashing.org; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 45ymx84tWtzDqQs for ; Wed, 31 Jul 2019 05:35:24 +1000 (AEST) Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x6UJZ30i024763; Tue, 30 Jul 2019 14:35:03 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x6UJZ26C024762; Tue, 30 Jul 2019 14:35:02 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 30 Jul 2019 14:35:02 -0500 From: Segher Boessenkool To: Arnd Bergmann Subject: Re: [PATCH] powerpc: workaround clang codegen bug in dcbz Message-ID: <20190730193502.GR31406@gate.crashing.org> References: <20190729202542.205309-1-ndesaulniers@google.com> <20190729203246.GA117371@archlinux-threadripper> <20190729215200.GN31406@gate.crashing.org> <20190730134856.GO31406@gate.crashing.org> <20190730161637.GP31406@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kbuild test robot , Nick Desaulniers , Linux Kernel Mailing List , clang-built-linux , Paul Mackerras , Nathan Chancellor , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Jul 30, 2019 at 08:24:14PM +0200, Arnd Bergmann wrote: > On Tue, Jul 30, 2019 at 6:16 PM Segher Boessenkool > wrote: > > in_le32 and friends? Yeah, huh. If LLVM copies that to the stack as > > well, its (not byte reversing) read will be atomic just fine, so things > > will still work correctly. > > byteorder is fine, the problem I was thinking of is when moving the load/store > instructions around the barriers that synchronize with DMA, or turning > them into different-size accesses. Changing two consecutive 16-bit mmio reads > into an unaligned 32-bit read will rarely have the intended effect ;-) Most such barriers will also work on the copy accesses, I think. But yes it depends on exactly how it is written. The {in,out}_{be,le} ones use sync;store for out and sync;load;trap;isync for in, so they should be safe ;-) (Well, almost -- writes to I/O will not necessarily actually happen before other stores, not from these macros alone at least). Should be pretty easy to check what LLVM makes of this? Segher