From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 1E76B3858D39 for ; Fri, 8 Oct 2021 17:40:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1E76B3858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 198HdGQd025076; Fri, 8 Oct 2021 12:39:16 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 198HdFl3025073; Fri, 8 Oct 2021 12:39:15 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 8 Oct 2021 12:39:15 -0500 From: Segher Boessenkool To: "Paul A. Clarke" Cc: gcc-patches@gcc.gnu.org, wschmidt@linux.ibm.com Subject: Re: [PATCH v3 1/6] rs6000: Support SSE4.1 "round" intrinsics Message-ID: <20211008173915.GR10333@gate.crashing.org> References: <20210823190310.1679905-1-pc@us.ibm.com> <20210823190310.1679905-2-pc@us.ibm.com> <20211007233906.GQ10333@gate.crashing.org> <20211008010423.GC243632@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211008010423.GC243632@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 17:40:18 -0000 On Thu, Oct 07, 2021 at 08:04:23PM -0500, Paul A. Clarke wrote: > On Thu, Oct 07, 2021 at 06:39:06PM -0500, Segher Boessenkool wrote: > > > + __asm__ __volatile__ ("mffsce %0" : "=f" (__fpscr_save.__fr)); > > > > The __volatile__ does likely not do what you want. As far as I can see > > you do not want one here anyway? > > > > "volatile" does not order asm wrt fp insns, which you likely *do* want. > > Reading the GCC docs, it looks like the "volatile" qualifier for "asm" > has no effect at all (6.47.1): > > | The optional volatile qualifier has no effect. All basic asm blocks are > | implicitly volatile. > > So, it could be removed without concern. This is not a basic asm (it contains a ":"; that is not just an easy way to see it, it is the *definition* of basic vs. extended asm). The manual explains: """ Note that the compiler can move even 'volatile asm' instructions relative to other code, including across jump instructions. For example, on many targets there is a system register that controls the rounding mode of floating-point operations. Setting it with a 'volatile asm' statement, as in the following PowerPC example, does not work reliably. asm volatile("mtfsf 255, %0" : : "f" (fpenv)); sum = x + y; The compiler may move the addition back before the 'volatile asm' statement. To make it work as expected, add an artificial dependency to the 'asm' by referencing a variable in the subsequent code, for example: asm volatile ("mtfsf 255,%1" : "=X" (sum) : "f" (fpenv)); sum = x + y; """ > > You do not need any of that __ either. > > I'm surprised that I don't. A .h file needs to be concerned about the > namespace it inherits, no? These are local variables in a function though. You get such complexities in macros, but never in functions, where everything is scoped. Local variables are a great thing. And macros are a bad thing! Segher