From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20132 invoked by alias); 24 Jan 2015 01:19:19 -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 20076 invoked by uid 89); 24 Jan 2015 01:19:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 24 Jan 2015 01:19:07 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id t0O1Ixt2032628; Fri, 23 Jan 2015 19:18:59 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id t0O1Iwg8032627; Fri, 23 Jan 2015 19:18:58 -0600 Date: Sat, 24 Jan 2015 07:23:00 -0000 From: Segher Boessenkool To: Jakub Jelinek Cc: Richard Henderson , Richard Biener , Jeff Law , 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: <20150124011858.GA31255@gate.crashing.org> References: <54B59964.7070707@redhat.com> <20150114000315.GA32710@gate.crashing.org> <54B609A9.9090800@redhat.com> <20150114151906.GA21784@gate.crashing.org> <54B74AD9.4010905@redhat.com> <20150115081330.GB1405@tucnak.redhat.com> <54C2B495.2010009@redhat.com> <20150123213940.GA17134@gate.crashing.org> <20150123214850.GZ1746@tucnak.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150123214850.GZ1746@tucnak.redhat.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg02154.txt.bz2 On Fri, Jan 23, 2015 at 10:48:50PM +0100, Jakub Jelinek wrote: > On Fri, Jan 23, 2015 at 03:39:40PM -0600, Segher Boessenkool wrote: > > I understand that argument. But it is not what GCC actually does, nor > > what I think it should do. Consider this program: > > > > --- 8< --- > > int main(void) > > { > > int x[100], y[100]; > > > > x[31] = 42; > > > > asm("# eww %0" : "=m"(y[4]) : : "memory"); > > > > return 0; > > } > > --- 8< --- > > Here x isn't addressable, so it is certainly fine to DSE it. > x shouldn't be considered memory. > If the address of x escaped, either to the assembly or to some global var > etc., then it probably shouldn't be removed. But GCC does consider it memory. If you look at the (tree) dump files you see both arrays are clobbered after the asm. Tree DCE removes the store to x[31] nevertheless. If the address of x escapes then of course the store to x[31] should not be removed, irrespective of whether the clobber implies a read or not. > > Here is another program: > > > > --- 8< --- > > int main(void) > > { > > int x; > > > > asm("# eww %0" : "=r"(x) : : "memory"); > > asm("# eww %0" : "=r"(x) : : "memory"); > > > > return x; > > } > > --- 8< --- > > > > If "memory" would imply a write and a read, the identical asm here could > > not be CSEd. But it is. > > Certainly not in GCC 4.9 nor trunk. I've committed the patch because it > makes GCC more aggressive again, just not for the "memory" case. Yes, sorry, it is not actually removed by the CSE pass, but much much earlier ("deleted 2 trivially dead insns" in the early RTL "jump" pass). My point is that much of the compiler does not agree that "memory" implies a read. But, to show RTL CSE removes the redundant insn here with older compilers: --- 8< --- int main(void) { int x1, x2; asm("# eww %0" : "=r"(x1) : : "memory"); asm("# eww %0" : "=r"(x2) : : "memory"); return x1 + x2; } --- 8< --- You can argue CSE should not do that. But other passes feel free to remove one of the asms (in the previous program), and they should not either if "memory" implies a read and a write. > In case of two idential non-volatile asms with "memory" clobber, > if there are no intervening memory reads or writes, we can talk about > allowing that to be CSEd despite "memory" being considered unspecified > read and write. If there are stores in between, we certainly should not CSE. If there is a store inbetween, we cannot remove the later asm, which is what CSE would do AFAIK. But we can remove the *earlier* asm (and, in fact, GCC does do that). Segher