From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104023 invoked by alias); 3 Feb 2017 08:55:39 -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 103993 invoked by uid 89); 3 Feb 2017 08:55:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=cures, equivalence, pr79286, PR79286 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; Fri, 03 Feb 2017 08:55:37 +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 233538553D; Fri, 3 Feb 2017 08:55:37 +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 v138tZ5p028038; Fri, 3 Feb 2017 03:55:36 -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: Date: Fri, 03 Feb 2017 08:55: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/msg00248.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. That seems pretty pessimistic -- do we have dominance information at this point? If so we could check that the assignment to the register dominates the use. If they are in the same block, then you have to look at LUIDs or somesuch. That would address the problem you're trying to solve without pessimizing the code. THe hell of it is I know I've poked at this problem in the past. jeff