From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33700 invoked by alias); 13 Dec 2018 23:49:45 -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 33614 invoked by uid 89); 13 Dec 2018 23:49:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=ams@codesourcery.com, sk:amscod, substitutes, U*ams 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; Thu, 13 Dec 2018 23:49:36 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7F5A2811DE; Thu, 13 Dec 2018 23:49:35 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-24.rdu2.redhat.com [10.10.112.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id A587C6B8E3; Thu, 13 Dec 2018 23:49:34 +0000 (UTC) Subject: Re: [PATCH 01/10] Fix LRA bug To: Andrew Stubbs , gcc-patches@gcc.gnu.org References: <37b228579c172c39ce89c75a673326b9185f92bc.1544611347.git.ams@codesourcery.com> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <20a62fb6-4e6b-2620-e142-0c3a50b71607@redhat.com> Date: Thu, 13 Dec 2018 23:49:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <37b228579c172c39ce89c75a673326b9185f92bc.1544611347.git.ams@codesourcery.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg01001.txt.bz2 On 12/12/18 4:52 AM, Andrew Stubbs wrote: > > [This is new patch not included in the previously posted patch sets.] > > This patch fixes an ICE building libgfortran/random.c. > > The problem was an adddi3 instruction that had an eliminable frame pointer. > GCN adddi3 includes a match_scratch, which LRA substitutes with a REG, and > checks if it can be converted back to a scratch afterwards. In the meantime, > the add was converted to a move, meaning that the instruction pattern > completely changed, thus causing a segfault when the instruction is revisited > in restore_scratches. I'm torn here. There's undocumented rules about this kind of stuff, largely inherited from the days of "reload". But I don't actually recall the specifics of any of those rules. I don't think there's any inherently wrong with what you've done in LRA. My worry is there's other places where this kind of changing the structure of the underlying insn is going to cause you problems if your patterns aren't following those undocumented rules. > > 2018-12-12 Andrew Stubbs > > gcc/ > * gcc/lra-int.h (lra_register_new_scratch_op): Add third parameter. > * gcc/lra-remat.c (update_scratch_ops): Pass icode to > lra_register_new_scratch_op. > * gcc/lra.c (struct sloc): Add icode field. > (lra_register_new_scratch_op): Add icode parameter. > Use icode to skip insns that have changed beyond recognition. OK. But be aware we may have to revisit and look more closely what what you're doing in your port if we stumble over more problems with reload changing the structure of your insns and causing problems in the process. jeff