From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27291 invoked by alias); 23 Jan 2015 21:49:03 -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 27274 invoked by uid 89); 23 Jan 2015 21:49:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 23 Jan 2015 21:49:00 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0NLmvH7001017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 23 Jan 2015 16:48:58 -0500 Received: from tucnak.zalov.cz (ovpn-116-98.ams2.redhat.com [10.36.116.98]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0NLmueb006462 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 23 Jan 2015 16:48:57 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t0NLmr1v017379; Fri, 23 Jan 2015 22:48:54 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t0NLmosi017378; Fri, 23 Jan 2015 22:48:50 +0100 Date: Fri, 23 Jan 2015 23:12:00 -0000 From: Jakub Jelinek To: Segher Boessenkool 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: <20150123214850.GZ1746@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20150113201322.GJ1405@tucnak.redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150123213940.GA17134@gate.crashing.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg02143.txt.bz2 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. > 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. 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. Jakub