From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43703 invoked by alias); 25 Feb 2016 08:47:38 -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 43670 invoked by uid 89); 25 Feb 2016 08:47:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-vk0-f65.google.com Received: from mail-vk0-f65.google.com (HELO mail-vk0-f65.google.com) (209.85.213.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 25 Feb 2016 08:47:36 +0000 Received: by mail-vk0-f65.google.com with SMTP id e185so2350189vkb.2 for ; Thu, 25 Feb 2016 00:47:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dZWLO9B4CiBG9OBCJdv8M+hvuUzWssFlsMUmUWjI8kA=; b=YP+zafwupLG/StAM0UylSzd8lI4fms8ZC2MUTJ1UCG8Hwi2RDleVtvrR5RmCy6YeHk YdszSwkLLoP6nnD78egCNG/VLAElKUljw5u7YiEBtPhTfARn0WvLXoSGq9y71vhbfRQ9 M8S+rl3+RGBzKaazYzpjJYCHeHC7fR2ztTb8bYaxkd+tlxvNjkVilh3/l9TrmgTd4laQ /Jpk+lgV2R3prvHrJl7E1Mixzb9gehBcvO4sqKrSJcMxA/FhM57pCX49Fq5DhQvDRFN1 n9U6nDELqeN5f+f9lRMQ3H5kQApmCG5XGa3FGGYVk68dmekqawHzwSux0KW1mqXG+d2X 6mvQ== X-Gm-Message-State: AG10YOTHPsUDGD2fFYVEz66dPfXeo+IKI3dxWeMDMI35nJl8aV/QHysPLWkkuE3ahY0+Tc+nZ2SLDcI55jZSAQ== MIME-Version: 1.0 X-Received: by 10.31.41.14 with SMTP id p14mr36386735vkp.151.1456390053843; Thu, 25 Feb 2016 00:47:33 -0800 (PST) Received: by 10.103.46.65 with HTTP; Thu, 25 Feb 2016 00:47:33 -0800 (PST) In-Reply-To: <56CEA194.1090204@redhat.com> References: <56BC34CE.20100@redhat.com> <56BD189A.1040409@redhat.com> <56C7962A.4010508@redhat.com> <56CEA194.1090204@redhat.com> Date: Thu, 25 Feb 2016 08:47:00 -0000 Message-ID: Subject: Re: [PATCH PR69052]Check if loop inv can be propagated into mem ref with additional addr expr canonicalization From: "Bin.Cheng" To: Jeff Law Cc: Bin Cheng , "gcc-patches@gcc.gnu.org" , nd Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg01695.txt.bz2 On Thu, Feb 25, 2016 at 6:39 AM, Jeff Law wrote: > On 02/22/2016 02:22 AM, Bin.Cheng wrote: > >>> My only question is why didn't you use FOR_EACH_SUBRTX_VRA from >>> rtl-iter.h >>> to walk the RTX expressions in collect_address_parts and >>> canonicalize_address_mult? >> >> Hi Jeff, >> Nothing special, just I haven't used this before, also >> canonicalize_address_mult is alphabetically copied from fwprop.c. One >> question is when rewriting SHIFT to MULT, we need to modify rtl >> expression in place, does FOR_EACH_SUBRTX iterator support this? If >> yes, what is the behavior for modified sub-expression? > > Hmm. The question of semantics when we change the underlying > sub-expressions is an interesting one. > > While I think we're OK in practice using the iterators, I think that's more > of an accident than by design -- if MULT/ASHIFT had a different underlying > RTL structure then I'm much less sure using the iterators would be safe. Hi Jeff, Yes, I thought about this too and finally decided to skip sub rtxes in modified MULT/ASHIFT expressions. I think this will make the patch with FOR_EACH_SUBRTX iterator safe. Although it doesn't dive into MULT/ASHIFT while the original one does, I don't think there is such case in practice, after all we can't handle such complicated address expression either. > > Let's go with your original patch that didn't use the iterators. Sorry for > making you do the additional work/testing to build the iterator version. Not even a problem. > But after pondering the issue you raised, I think your original patch is > safer. So in conclusion, I think both versions should be safe, the iterator one is definitely cleaner. It is your call which version I should apply. Thanks, bin > > > jeff