From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6321 invoked by alias); 13 Jan 2015 23:47:02 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 6308 invoked by uid 89); 13 Jan 2015 23:47:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.3.2 X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 13 Jan 2015 23:46:59 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YBBAg-00018u-EV for gcc-patches@gcc.gnu.org; Tue, 13 Jan 2015 18:46:57 -0500 Received: from gate.crashing.org ([63.228.1.57]:43558) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YBBAf-00017e-Hy for gcc-patches@gcc.gnu.org; Tue, 13 Jan 2015 18:46:50 -0500 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id t0DMSWwc031932; Tue, 13 Jan 2015 16:28:33 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id t0DMSVs8031927; Tue, 13 Jan 2015 16:28:31 -0600 Date: Wed, 14 Jan 2015 00:40:00 -0000 From: Segher Boessenkool To: Jeff Law Cc: Jakub Jelinek , Richard Biener , Eric Botcazou , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Reenable CSE of non-volatile inline asm (PR rtl-optimization/63637) Message-ID: <20150113222831.GA31575@gate.crashing.org> References: <20150113161819.GD1405@tucnak.redhat.com> <20150113163840.GA4183@gate.crashing.org> <54B575D7.8030107@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54B575D7.8030107@redhat.com> User-Agent: Mutt/1.4.2.3i X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 63.228.1.57 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00959.txt.bz2 Message-ID: <20150114004000.iTIn50mwEZJERfETDSXDjKVU9CugHvtqK-HgQwxF89s@z> On Tue, Jan 13, 2015 at 12:45:27PM -0700, Jeff Law wrote: > On 01/13/15 09:38, Segher Boessenkool wrote: > >On Tue, Jan 13, 2015 at 05:18:19PM +0100, Jakub Jelinek wrote: > >>3) on request from Richard (which Segher on IRC argues against), "memory" > >> clobber also prevents CSE; > > > >As extend.texi used to say: > > > >" > >If your assembler instructions access memory in an unpredictable > >fashion, add @samp{memory} to the list of clobbered registers. This > >causes GCC to not keep memory values cached in registers across the > >assembler instruction and not optimize stores or loads to that memory. > >You also should add the @code{volatile} keyword if the memory > >affected is not listed in the inputs or outputs of the @code{asm}, as > >the @samp{memory} clobber does not count as a side-effect of the > >@code{asm}. > >" > > > >so a "memory" clobber in a non-volatile asm should not prevent CSE. > My reading of that paragraph is somewhat different. It seems so. I read that as "GCC can delete a memory clobber if it wants to" (just like it can delete any other clobber when it wants to). The only difference between ASM_OPERANDS and any other RTL is that recog is useless for ASM_OPERANDS, it cannot tell you if after you modify the construct you are left with something valid; so the only thing the compiler can change about an asm is to delete it whole. So unlike most RTL, where the compiler is free to remove a clobber if what is left is valid RTL, the only way to delete a clobber from an asm is to delete the whole asm. > The key here is the memory clobber affects optimization of instructions > around the asm while the volatile specifier affects the optimization of > the ASM itself. Those are roughly the effects, yes. Writing unspecified stuff to unspecified memory is a pretty heavy hammer ;-) > A memory clobber must inhibit CSE of memory references on either side of > the asm because the asm must be assumed to read or write memory in > unpredictable ways. I don't see how that follows. The asm itself can be CSEd; its clobber then disappears in a puff of smoke. > The volatile specifier tells the compiler that the asm itself must be > preserved, even if dataflow shows the outputs as not used. Yes. Segher