From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117941 invoked by alias); 4 Feb 2017 00:08:17 -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 117853 invoked by uid 89); 4 Feb 2017 00:08:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*M:d7aa, quality 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 ESMTP; Sat, 04 Feb 2017 00:08:14 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 894E380469; Sat, 4 Feb 2017 00:08:14 +0000 (UTC) Received: from localhost.localdomain (ovpn-120-20.rdu2.redhat.com [10.10.120.20] (may be forged)) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1408DX2003001; Fri, 3 Feb 2017 19:08:14 -0500 Subject: Re: PR79286, ira combine_and_move_insns in loops To: Alan Modra , gcc-patches@gcc.gnu.org References: <20170201134830.GA3731@bubble.grove.modra.org> <20170201213722.GB3731@bubble.grove.modra.org> <20170202093138.GF3731@bubble.grove.modra.org> From: Jeff Law Message-ID: <7b9c45e8-02b0-d7aa-ccdc-9ceeb49c8f24@redhat.com> Date: Sat, 04 Feb 2017 00:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170202093138.GF3731@bubble.grove.modra.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00320.txt.bz2 On 02/02/2017 02:31 AM, Alan Modra wrote: > Revised patch that cures the lra related -m32 -Os regression too. > > The code that I'm patching here is changing a REG_EQUAL note to > REG_EQUIV, ie. asserting that the value of the reg is always the value > set by the current instruction. Which is not always true when the > insn is in a loop and the use of the reg happens before the def. Of > course that implies the value of the reg is initially undefined, so > it's not unreasonable to make the initial reg value the same. > Except when the code setting the initial value may trap, as it does in > the testcase. > > Bootstrap and regression test on x86_64-linux in progress. OK > assuming no regressions? > > I also took a look at gcc/*.o to see whether there were any code > quality regressions. No differences found except the expected change > in ira.o. > > PR rtl-optimization/79286 > * ira.c (update_equiv_regs): Do not create an equivalence for > mems that may trap. > testsuite/ > * gcc.c-torture/execute/pr79286.c: New. So I haven't been able to find where we've hashed through this issue before. My recollection was that if we encountered a use before the def that we would avoid recording the equivalence when we later see the REG_EQUAL note. That works within a BB. If the use/set are in different blocks then don't we just need to check that the set dominates the use? Jeff