From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16025 invoked by alias); 11 Oct 2018 18:18:53 -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 16005 invoked by uid 89); 11 Oct 2018 18:18:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:db00fba, H*f:sk:a0aa34c, H*f:sk:t9m_N6_, H*f:sk:CAMe9rO X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 Oct 2018 18:18:51 +0000 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w9BIGZZl093935 for ; Thu, 11 Oct 2018 14:18:49 -0400 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by mx0a-001b2d01.pphosted.com with ESMTP id 2n28hvtads-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 11 Oct 2018 14:18:49 -0400 Received: from localhost by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 11 Oct 2018 12:18:48 -0600 Received: from b03cxnp08027.gho.boulder.ibm.com (9.17.130.19) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 11 Oct 2018 12:18:46 -0600 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w9BIIjGm51118290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 11 Oct 2018 11:18:45 -0700 Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D1F697805C; Thu, 11 Oct 2018 12:18:45 -0600 (MDT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C06347805E; Thu, 11 Oct 2018 12:18:44 -0600 (MDT) Received: from otta.local (unknown [9.80.238.11]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 11 Oct 2018 12:18:44 -0600 (MDT) Subject: Re: [PATCH 2/2 v3][IRA,LRA] Fix PR86939, IRA incorrectly creates an interference between a pseudo register and a hard register From: Peter Bergner To: Jeff Law , Vladimir Makarov Cc: Christophe Lyon , gcc Patches References: <14bf79ef-9db2-e76b-df10-fcb2574d5ccb@linux.ibm.com> <121ca751-fb38-d7e1-bffd-89df22a2fdd7@redhat.com> <05a29347-7a39-a1e6-42b8-16c779b97eb5@redhat.com> <703aaa46-eac5-63d1-22dc-0cd31a0e840f@redhat.com> <276824e1-6306-1ac6-b6ba-6b11eac615e7@linux.ibm.com> <191bf9ee-98c4-b87e-cc65-40e1fb5de0ea@linux.ibm.com> Date: Thu, 11 Oct 2018 18:26:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit x-cbid: 18101118-8235-0000-0000-00000E123441 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009861; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000268; SDB=6.01101207; UDB=6.00569815; IPR=6.00881253; MB=3.00023715; MTD=3.00000008; XFM=3.00000015; UTC=2018-10-11 18:18:48 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18101118-8236-0000-0000-000042F5D637 Message-Id: <478a817c-719b-9c3c-5b38-de7b277d9f93@linux.ibm.com> X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00684.txt.bz2 On 10/10/18 7:57 PM, Peter Bergner wrote: > The problem is, that hard reg %r26 is defined in insn 32, to be used in > insn 33, so using %r26 as the reload reg is wrong, because it will clobber > the value we set in insn 32. Looking thru LRA, it looks like LRA assumes > that for a reload, if one of the input pseudos dies in the insn, then the > hard reg it was assigned to is available to use. That assumption is (now) > wrong, because another pseudo may be using that hard reg or in this case, > the hard reg itself is still live. > > For this example, pseudo 109 also dies in insn 49 and since it's hard reg > %r28 isn't live thru the insn, we could have used that instead. However, > we cannot just look at REG_DEAD notes for free hard regs to use for reload > regs. We need to make sure that that hard reg isn't also assigned to another > pseudo that is live at that insn or even that the hard reg itself is live. > > Vlad, you know the LRA code better than anyone. Will it be easy to find > all the places where we create reload regs and fix them up so that we > look at more than just REG_DEAD notes? Even though looking at REG_DEAD > notes isn't enough, I still think the majority of the time those regs > probably will be free to use, we just have to check for the special > cases like above where they are not. Ok, after working in gdb, I see that the PA-RISC port still uses reload and not LRA, but it too seems to have the same issue of reusing input regs that have REG_DEAD notes, so the question still stands. It's just that whatever fix we come up with will have to be to both LRA and reload. Peter