From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12587 invoked by alias); 6 Aug 2014 08:35:43 -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 12576 invoked by uid 89); 6 Aug 2014 08:35:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Aug 2014 08:35:41 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Wed, 06 Aug 2014 09:35:38 +0100 Received: from [10.1.208.33] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Aug 2014 09:35:36 +0100 Message-ID: <53E1E8D7.4090706@arm.com> Date: Wed, 06 Aug 2014 08:35:00 -0000 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jeff Law CC: "gcc-patches@gcc.gnu.org" , "rdsandiford@googlemail.com" Subject: Re: [PATCH 17/50] df-problems.c:find_memory References: <87y4v5d77q.fsf@googlemail.com> <87wqapacyp.fsf@googlemail.com> <53E14CB2.1030409@redhat.com> In-Reply-To: <53E14CB2.1030409@redhat.com> X-MC-Unique: 114080609353812501 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00445.txt.bz2 On 05/08/14 22:29, Jeff Law wrote: > On 08/03/14 08:02, Richard Sandiford wrote: >> This also fixes what I think is a bug: find_memory used to stop at the >> first MEM it found. If that MEM was nonvolatile and nonconstant, we'd >> return MEMREF_NORMAL even if there was another volatile MEM. >> >> >> gcc/ >> * df-problems.c: Include rtl-iter.h. >> (find_memory): Turn from being a for_each_rtx callback to being >> a function that examines each subrtx itself. Continue to look for >> volatile references even after a nonvolatile one has been found. >> (can_move_insns_across): Update calls accordingly. > OK. >=20 > It'd probably be fairly difficult to test for that bug as most of our=20 > targets don't allow multiple memory operands in a single insn. But I=20 > agree with your assessment. Good catch. >=20 > jeff >=20 >=20 ARM (and AArch64) have patterns with multiple MEMs; but the mems have to be related addresses and (I think) be non-volatile (certainly if volatile is permitted in one MEM it must also be in the others within the pattern). Patterns generally enforce all of this through the pattern itself, the constraints or the condition on the insn. R.