From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84887 invoked by alias); 29 Apr 2015 21:58:11 -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 84874 invoked by uid 89); 29 Apr 2015 21:58:10 -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) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Apr 2015 21:58:09 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by uk-mta-21.uk.mimecast.lan; Wed, 29 Apr 2015 22:58:01 +0100 Received: from e104437-lin ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2015 22:58:01 +0100 References: <5539A922.7060708@redhat.com> <554054E9.4030400@redhat.com> From: Jiong Wang To: Jeff Law Cc: "gcc-patches\@gcc.gnu.org" Subject: Re: [Patch/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding Date: Wed, 29 Apr 2015 22:14:00 -0000 In-reply-to: <554054E9.4030400@redhat.com> Message-ID: MIME-Version: 1.0 X-MC-Unique: C74I4v7RReaSFcbD2vQF-Q-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-04/txt/msg01940.txt.bz2 Jeff Law writes: > On 04/27/2015 02:21 PM, Jiong Wang wrote: > >> Jeff, >> >> Sorry, I can't understand the meaning of "overlap between t_low and l= ow", >> assume "right" in "right value" means the opposite of "left" not >> "correct". >> >> So what you mean is t_low and low share the same pseudo regiser? > My concern is sharing the same pseudo or memory location. But thinking=20 > more about it, the shifted value has to have range information, so it=20 > must have been an SSA_NAME, right? If so, then it can't overlap with=20 > the destination, so this is a non-issue. Sorry for the confusion. Thanks for the light. By looking at related code, looks like even it's SSA_NAME, it's still possible to share the same pseudo given the destination is in the same SSA map parition after ssa name coleascing?=20= =20=20 > I've never liked the model of storing into TARGET when it's convenient.=20 > Because storing into TARGET is totally optional, it means the callers=20 > have to check if the value was stored into TARGET or not. > > Sadly that model has been in the expanders as long as I can remember. > > So I think this can go forward once we resolve the case where=20 > expand_variable_shift returns its value in something other than the=20 > passed in target. OK. I will rework the patch, and I found there is a function named "expand_doubleword_shift" which looks like a more natural place to do this optimization, although it's hard to get range info there. I will do further explore on this. --=20 Regards, Jiong