From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31006 invoked by alias); 2 Sep 2014 13:41: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 30926 invoked by uid 89); 2 Sep 2014 13:41:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 02 Sep 2014 13:41:16 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id s82DeqxS020992; Tue, 2 Sep 2014 08:40:52 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id s82DepNW020986; Tue, 2 Sep 2014 08:40:51 -0500 Date: Tue, 02 Sep 2014 13:41:00 -0000 From: Segher Boessenkool To: Ulrich Weigand Cc: Jeff Law , "Bin.Cheng" , Richard Earnshaw , Bin Cheng , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH PR62151]Fix uninitialized register issue caused by distribute_notes in combine pass Message-ID: <20140902134050.GA13829@gate.crashing.org> References: <20140901175036.GA6643@gate.crashing.org> <201409021210.s82CAWsP031216@d06av02.portsmouth.uk.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201409021210.s82CAWsP031216@d06av02.portsmouth.uk.ibm.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00127.txt.bz2 On Tue, Sep 02, 2014 at 02:10:32PM +0200, Ulrich Weigand wrote: > In any case, this test in can_combine_p rejects a combination for *two* > different issues. One is the earlyclobber problem, which is what that > 2004 thread was about, and which my patch back then relaxed for fixed > hard register. > > However, this doesn't seem to apply to the example above; that is really > about the second problem: don't substitute into a clobber. Right. > I understand the reason why this particular substitution is rejected is > simply that if it weren't, we'd be substituting flags:CC=cmp(r84:SI,0x1) > into clobber flags:CC, resulting in clobber cmp(r84:SI,0x1), which is > invalid RTL. I checked, and that is indeed what combine does. How silly. > Now I guess this check could be relaxed if somewhere else in combine we'd > recognize the substitution into a clobber and simply omit it in that case. Yeah. In the testcase, combine tries combining 76,77 (77 is that clobbering insn) and refuses it; then it tries 32,76,77 and refuses it; and then it tries 32,76,77,43 and allows it (it doesn't do this check at all, 77 is not i3, combine omits the clobber completely). Which is inconsistent. What a mess. Thanks for looking! Segher