From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14834 invoked by alias); 24 Feb 2017 10:04:27 -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 14813 invoked by uid 89); 24 Feb 2017 10:04:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-23.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=life X-HELO: mail-oi0-f47.google.com Received: from mail-oi0-f47.google.com (HELO mail-oi0-f47.google.com) (209.85.218.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Feb 2017 10:04:25 +0000 Received: by mail-oi0-f47.google.com with SMTP id 65so8338710oig.1 for ; Fri, 24 Feb 2017 02:04:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GFblM26m6tfOQz2GVZ8Ut8hXIjxxbDpVnLwUAHlzSHA=; b=n4CXj7JuG4nr+evIiYLYNY2tbAWWu5NbFeE6Lz00HmFqGGDhvxxDwy96RM66++PK+M bd4aakD7gmxuqfPKfLh8zWMhGU09WzUVnEOVgrHNGlBeRl4Mmc4kkeWyJ6n/DJ5+tOGi 1P4WX7id7lUMluMD22MLovmWnu8Irt35Za0kB5Ar4/+huaNwy3SFPVN9nhQc3GTAmdPt xAbEIKp6+hiy7bdztN8yWGZNl9J1Rb/K9Kq4Z9D/33OupTnTeELCsRj/jbGI7wLaEquX NCOXIaTvQeFaVeGVdZwRXKleM0LDGxalDfluT9jsT+VhSPVpwBdVMEcGhBVSCMsux8el +oSQ== X-Gm-Message-State: AMke39lx0quEzC1ZWO+5qqjO/LQ6PwCXUNpvO90n9E7aZobiJDx40HyyYaWD9tWYkIotM+msGlghP4FVrthZ9w== X-Received: by 10.202.72.76 with SMTP id v73mr935675oia.123.1487930663796; Fri, 24 Feb 2017 02:04:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.40.120 with HTTP; Fri, 24 Feb 2017 02:04:23 -0800 (PST) In-Reply-To: <069f125b-f064-97da-7bbf-219fc15d6ff4@redhat.com> References: <5d9c026a-12a7-d6f7-e1d7-da0382ac8f2a@redhat.com> <069f125b-f064-97da-7bbf-219fc15d6ff4@redhat.com> From: Richard Biener Date: Fri, 24 Feb 2017 10:05:00 -0000 Message-ID: Subject: Re: [PATCH][PR tree-optimization/79578] Use operand_equal_p rather than pointer equality for base test To: Jeff Law Cc: gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg01485.txt.bz2 On Thu, Feb 23, 2017 at 10:06 PM, Jeff Law wrote: > On 02/23/2017 02:02 AM, Richard Biener wrote: > >>> diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c >>> index 84c0b11..a82e164 100644 >>> --- a/gcc/tree-ssa-dse.c >>> +++ b/gcc/tree-ssa-dse.c >>> @@ -176,7 +176,7 @@ clear_bytes_written_by (sbitmap live_bytes, gimple >>> *stmt, ao_ref *ref) >>> /* Verify we have the same base memory address, the write >>> has a known size and overlaps with REF. */ >>> if (valid_ao_ref_for_dse (&write) >>> - && write.base == ref->base >>> + && operand_equal_p (write.base, ref->base, 0) >> >> >> As you've identified size and offset match you are really interested >> in comparing the base addresses and thus should use OEP_ADDRESS_OF. > > I pondered that, but (perhaps incorrectly) thought that OEP_ADDRESS_OF was > an optimization and that a more simple o_e_p with no flags was safer. > > I'm happy to change it, particularly if it's a correctness issue (in which > case I think we've designed a horrible API for o_e_p, but such is life). In > fact, I've already bootstrapped and regression tested that change. It's indeed an optimization to use OEP_ADDRESS_OF and 0 is more conservative. Richard. > jeff >