From patchwork Thu Feb 27 12:23:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Stubbs X-Patchwork-Id: 1245794 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-520238-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha1 header.s=default header.b=WOGH1iah; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 48SsKR74pTz9sRR for ; Thu, 27 Feb 2020 23:23:54 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :subject:to:message-id:date:mime-version:content-type; q=dns; s= default; b=iAg29Wkb+2glr302FJKulOkuCJ6FbVifmsECSjCqljvU2xteeKc7W eroophAiz66OzL1dLd5C4IsEriLji2jyMHFfBRXVc37yl+ZqWrUcil8xg28w78a/ 5uIZtcJOy4VIdsNDU9JWlgBNAMz+ss2v25KSFBvPoKxIbwuab6on3g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :subject:to:message-id:date:mime-version:content-type; s= default; bh=HtX4SOz+7uPFkHw2LrQfRwRBd8I=; b=WOGH1iahISexhj1A5/rU hzxbXtmbRfOcUs4o+S4r+bI1NMI5uME+GFq/cso+4Hdmu4MtY2vDWlo64JPP60mw cVxZwwNucBqWjk+4s21tUV8WKUTmD7NOSRAa/dmdm/3GJSONWur2yhhq8DwjytDK /Y7435aIwhNZlPSuvstFPpE= Received: (qmail 127616 invoked by alias); 27 Feb 2020 12:23:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 127605 invoked by uid 89); 27 Feb 2020 12:23:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-18.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS, UNSUBSCRIBE_BODY autolearn=ham version=3.3.1 spammy=HContent-Language:en-GB X-HELO: esa2.mentor.iphmx.com Received: from esa2.mentor.iphmx.com (HELO esa2.mentor.iphmx.com) (68.232.141.98) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Feb 2020 12:23:45 +0000 IronPort-SDR: JHRiuB0CLCYF4YxrropSrpKs2bzKg04hgXVd/jw6VLvXrULQp2W5S2cYjo27Pg4tWhq4kTZX75 Mui3KddhaXKLyP2GaG4Sbxrq1+9FqZNEXqFDyMNymBSaQXem4X7lnbFTkfFVOPHiHk5T2fEnLH uRIcEboiWDRSL8Gjk4ARvtiWaTUSgCRJZyNtUundaZ6qWxx7NEfBuLmBzRb2ryjjMP20bgrgXz UKdM8vbhUu8V33UlvtamF0i9hI+KMzmEDT6grU7n1YsPev1aRCVs0oRcl7D0i87jdDHs/56O89 z1Q= Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 27 Feb 2020 04:23:38 -0800 IronPort-SDR: pbQJK99oGat3gf9i7q6JEUFXrmzV6+ZVK4dH5qL04ZXXvStnx9vAvKCQnuPMIHQs5BsgEoQoWR whW79DkllJMXX35FqrXXd8iyIniJPVKyX4EznfrFv9XQvuehsPDOt+M8/bnegeU6aqDQcHD8bu bVMKYvvP07MYw7Zp4iNkF5EoW4+Ywq9yvrevMKL8nDIMy4G5ojsjSGhzjgLzD9dNbCxySJTpmv LtC1Va/KPRV457vfu/0NH8TeWsYA+6Fe/Qb0CDAz3+5s4Dl9CJZCebEXpkkRer1dKKEn/s78lT Pww= From: Andrew Stubbs Subject: [committed] amdgcn: fix ICE on subreg of BI reg To: "gcc-patches@gcc.gnu.org" Message-ID: Date: Thu, 27 Feb 2020 12:23:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 This patch fixes an LRA ICE that was exposed by another patch on Sunday. I can't see any reason why that patch should cause an ICE, so presumably it merely perturbed something. The problem was that LRA with checking enabled was confirming that all the registers it had allocated are considered "ever live", and found that the high-part of the VCC register was not live. The reason was that it had created an instruction like this: (set (reg:SI s2) (subreg:SI (reg:BI VCC) 0)) This seems like it ought to be fine, except that gcn.c defines (reg:BI VCC) to have nregs == 2, whereas (reg:SI VCC) nregs == 1. The checking code uses nregs from the inner register mode, and DF uses nregs from the outer subreg mode, and the mismatch causes the ICE. Using 64-bits for a BImode register is unusual but makes sense because instructions writing BImode condition codes to VCC will normally clobber the entire DImode register pair, whereas SImode register modes only touch one of the two registers. The solution is to transform the instruction like this: (set (subreg:BI (reg:SI s2) 0) (reg:BI VCC)) This says approximately the same thing, but now nregs is firmly "2", and the ICE goes away. Andrew amdgcn: fix ICE on subreg of BI reg. BImode usually only requires one bit, but instructions that write to VCC also clobber the reset of the DImode register pair, so gcn_class_max_nregs reports that two registers are needed for BImode. Paradoxically, accessing VCC via SImode is therefore uses fewer registers than accessing via BImode. The LRA checking code takes this into account, but the DF liveness data also looks at the subreg, so it says (subreg:SI (reg:BI VCC) 0) only makes the low part live. Both are "correct", but they disagree, which causes an ICE. This doesn't happen when writing conditions to VCC; it happens when accessing VCC_LO via a regular move to a regular SImode register. If we transform the subregs so that BImode is always the outer mode then it basically means the same thing, except that now both LRA and DF calculate nregs the same, and ICE goes away. As soon as LRA is done the subregs all evaporate anyway. 2020-02-27 Andrew Stubbs gcc/ * config/gcn/gcn.md (mov): Add transformations for BI subregs. diff --git a/gcc/config/gcn/gcn.md b/gcc/config/gcn/gcn.md index b527d9a7a8b..d8b49dfd640 100644 --- a/gcc/config/gcn/gcn.md +++ b/gcc/config/gcn/gcn.md @@ -395,6 +395,31 @@ (match_operand:MOV_MODE 1 "general_operand"))] "" { + if (SUBREG_P (operands[1]) + && GET_MODE (operands[1]) == SImode + && GET_MODE (SUBREG_REG (operands[1])) == BImode) + { + /* (reg:BI VCC) has nregs==2 to ensure it gets clobbered as a whole, + but (subreg:SI (reg:BI VCC)) doesn't, which causes the LRA liveness + checks to assert. Transform this: + (set (reg:SI) (subreg:SI (reg:BI))) + to this: + (set (subreg:BI (reg:SI)) (reg:BI)) */ + operands[0] = gen_rtx_SUBREG (BImode, operands[0], 0); + operands[1] = SUBREG_REG (operands[1]); + } + if (SUBREG_P (operands[0]) + && GET_MODE (operands[0]) == SImode + && GET_MODE (SUBREG_REG (operands[0])) == BImode) + { + /* Likewise, transform this: + (set (subreg:SI (reg:BI)) (reg:SI)) + to this: + (set (reg:BI) (subreg:BI (reg:SI))) */ + operands[0] = SUBREG_REG (operands[0]); + operands[1] = gen_rtx_SUBREG (BImode, operands[1], 0); + } + if (MEM_P (operands[0])) operands[1] = force_reg (mode, operands[1]);