From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13752 invoked by alias); 2 Sep 2014 03:40:21 -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 13727 invoked by uid 89); 2 Sep 2014 03:40:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 02 Sep 2014 03:40:14 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s823e98C000861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 1 Sep 2014 23:40:09 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-89.phx2.redhat.com [10.3.113.89]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s823e8q7012318; Mon, 1 Sep 2014 23:40:08 -0400 Message-ID: <54053C18.3040500@redhat.com> Date: Tue, 02 Sep 2014 03:40:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "Bin.Cheng" CC: Richard Earnshaw , Bin Cheng , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH PR62151]Fix uninitialized register issue caused by distribute_notes in combine pass References: <000a01cfc1de$cac1c230$60454690$@arm.com> <53FDB440.5030904@arm.com> <5401680D.60907@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00093.txt.bz2 On 08/31/14 22:18, Bin.Cheng wrote: >> >> Note that i0..i4 need not be consecutive insns, so you'd have to walk the >> chain from the location with the death note to the proposed death note site. >> If between those locations there's another set of the same pseudo, then drop >> the note. Since this may be an expensive check it should probably be >> conditionalized on REG_N_SETS (pseudo) > 1 > > Here is the complicated part. The from_insn is i1, i2/i3 are the > following instructions. The original logic seems to me is scanning > from i3 for one insn for distribution of REG_DEAD note in from_insn. > Since the last use is in from_insn, it makes no sense to scan from i3 > (after from_insn). What we need to do is scanning from from_insn in > backward trying to find a place for note distribution. If we run into > a useless set of the note reg, we can just delete that insn or add > REG_UNUSED to it. It just seems not right to do this on instructions > after from_insn, which causes the wrong code in this specific case. I wasn't suggesting we add a REG_UNUSED or delete anything. Merely look to see if between the original note's location and new proposed location for the note. If there's another assignment to the same pseudo in that range of insns, then simply remove the note. What happens if you do that? It seems to me that adding a REG_UNUSED or trying to delete any insns at this stage is just a complication we don't really need. jeff