From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59210 invoked by alias); 17 Nov 2015 13:03:32 -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 59189 invoked by uid 89); 17 Nov 2015 13:03:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (207.82.80.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Nov 2015 13:03:30 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-4-9_R99vB7SIyqNRt86tmNKA-1; Tue, 17 Nov 2015 13:03:23 +0000 Received: from [10.2.206.200] ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Nov 2015 13:03:22 +0000 Message-ID: <564B259A.90206@arm.com> Date: Tue, 17 Nov 2015 13:03:00 -0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bernd Schmidt , GCC Patches CC: Jeff Law Subject: Re: [PATCH][RTL-ree] PR rtl-optimization/68194: Restrict copy instruction in presence of conditional moves References: <5649E333.4090904@arm.com> <564A2339.3030308@redhat.com> <564AEE94.3070708@arm.com> <564B1934.6050300@redhat.com> In-Reply-To: <564B1934.6050300@redhat.com> X-MC-Unique: 9_R99vB7SIyqNRt86tmNKA-1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02081.txt.bz2 On 17/11/15 12:10, Bernd Schmidt wrote: > On 11/17/2015 10:08 AM, Kyrill Tkachov wrote: >> Yes, I had considered that as well. It should be equivalent. I didn't >> use !reg_used_between_p because I thought >> it'd be more expensive than checking reg_overlap_mentioned_p since we >> must iterate over a number of instructions >> and call reg_overlap_mentioned_p on each one. But I suppose this case is >> rare enough that it wouldn't make any >> measurable difference. >> >> Would you prefer to use !reg_used_between_p here? > > I would but apparently it doesn't work, so that's kind of neither here no= r there. > >>> The added comment could lead to some confusion since it's placed in >>> front of an existing if statement that also tests a different >>> condition. Also, if we go with your fix, >>> >>>> + || !reg_overlap_mentioned_p (tmp_reg, SET_SRC (PATTERN >>>> (cand->insn)))) >>> >>> Shouldn't this really be !rtx_equal_p? >>> >> >> Maybe, will it behave the right way if the two regs have different modes >> or when subregs are involved? > > It would return false, in which case we'll conservatively fail here. I th= ink that's desirable? > Well, I think the statement we want to make is "return false from this function if the two expressions contain the same re= gister number". if (!rtx_equal_p (..., ...)) return false; will only return false if the two expressions are the same REG with the sam= e mode. if (!reg_overlap_mentioned_p (..., ...)) return false; should return false even if the modes are different or one is a subreg, whi= ch is what we want. I did not see any codegen regressions using reg_overlap_mentioned_p on aarc= h64, so I don't think it will restrict any legitimate cases. Thanks, Kyrill > > Bernd >