From patchwork Wed Nov 22 14:27:55 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Stubbs X-Patchwork-Id: 168396 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2b07:b0:403:3b70:6f57 with SMTP id io7csp1362198vqb; Wed, 22 Nov 2023 06:28:25 -0800 (PST) X-Google-Smtp-Source: AGHT+IGh34WPNTkGFUqxA071g7C3H2MrksSUhEcHq9BPyY9Qz/I/w2EiFJ/hhF+mUs7Zvj00+ndy X-Received: by 2002:a05:6808:171c:b0:3b6:cc44:20e6 with SMTP id bc28-20020a056808171c00b003b6cc4420e6mr2705432oib.11.1700663305250; Wed, 22 Nov 2023 06:28:25 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1700663305; cv=pass; d=google.com; s=arc-20160816; b=DFcvpzn/gUAgF1+aENJatGzVeBYVczJzzZKOQ6k4G3BjHKUS92dux3hu0Wxf1FRfyE uQ/DjaLL8LLTZQUIWvVKs0dn12Lv5MBaoYWOCChv6DZFZji1uS7y1GNBrT4dGQ7WAY35 tHT21YeonDHdjDq76/cJGB7vMBICCGaoJEA0LmMgEGJ19gqU9vCrGMIYMkWjMmk0EY+v 8XoVbFI79J7HSJBo5iAXz/7+dtWdagT0x7XnCYf6aCtJzj9bIkCNLWiQ3FOGEvUOUleN IE/+ab74ljtlDBtfhASbBC2xnZzYPvm4tQX6LFtX/n+zNe1P4BIvNIjQL2vP4FZ50lN4 0Luw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:to:subject:from :content-language:user-agent:mime-version:date:message-id :ironport-sdr:arc-filter:dmarc-filter:delivered-to; bh=L7PsOkw1myFwG2+WVGrP2BgWl5G0vVLZu65bQtVH5O8=; fh=XNn3asQvIblazGK92GBt13dVv+YmGV3pBS0JC29ZQco=; b=JsOImFkrtv76Ydh05x51X1Dy3WWUJrw+W6ZGjc7U3bkwSZ4BpQrZmLgIhVxGtb3ht5 FthxJ8CE+8Z/kNNY44o6YeNtcep5RPhR2CvdOYE0WYp1nDRgr2AC9p5UyDijNOnkxAqf GdiQ2oTmlDqi9nEN+UXglG1cg5MkVvPWtIOr7vbGJgsQYvWBf4Q8zAy7Nmwb+mS7Dult shP0lWn2Q9R1dg4ehXyTFpODzbTo2WFM7X4YYMD2QBL+yVr+8sW9vG/yKbeTFaxWTodD jx4ffrQx11RJj1vi3Pj0LHQxm6F0HMQPJ5MBUDBuMCVCYHDFDFc2dmczheRWkm6AGnzV S8zg== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from server2.sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id j9-20020a056214022900b006592a95dde8si11061763qvt.87.2023.11.22.06.28.25 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Nov 2023 06:28:25 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 01BD23858C52 for ; Wed, 22 Nov 2023 14:28:25 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 96AAD3858D39 for ; Wed, 22 Nov 2023 14:28:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 96AAD3858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 96AAD3858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=68.232.141.98 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700663282; cv=none; b=eoSWN/sne9hBYiqDMwbwguKTIpoI38EF7CiKRaDim98UEkWg9OYYjuMxtGyaZt684uTyXNoOyylmsy/x7aVt4PYjGSTAD4bvwYKpGiDGFvnn1EK5igTt8+6WYtmsuHG8spbRUqrX9rqbKbxKfY/MSrxA3WOOXJmc/EBTM/o0SUM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700663282; c=relaxed/simple; bh=5YVEMMsS6+9N0C0W7P5LI+qZG5Az6B3ok+OogOqxSTM=; h=Message-ID:Date:MIME-Version:From:Subject:To; b=xzH2koujgs4NbvKN13XxXizfdGRXbymqaF+GeRj9q//LR+WrSMykGGqArMGfcdqs1lLuszNEenVWJ3u2IymSCxfnnyoAJ3FA3tWkK7YmlahMTTHzskk2TGfuFFkizSH7aZMZ7EYnZNcj0MUj9Q9R9z1SHOxy3W4w52mPcBAyxVg= ARC-Authentication-Results: i=1; server2.sourceware.org X-CSE-ConnectionGUID: ZdZQqJZFTs2qcqkEZ4/DXQ== X-CSE-MsgGUID: nE8L+dnTR3m4uPJ5JVI7rQ== X-IronPort-AV: E=Sophos;i="6.04,219,1695715200"; d="scan'208";a="26248058" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 22 Nov 2023 06:27:59 -0800 IronPort-SDR: dDlXKCyBaA6Tz1ZaNqWBTGh7BNtG8rot8W0gq9M1vmgxBU3tE9NYlHAszB1mmxh0CUeII/vXXr EiLpqqR9YH0NlkgGpNEEjswfEoKY1Gkux/pIv9GwHewJ7zhGz7v2g1+/xiDjW0clcbN5X96kki HLHFDvXvmHe9RBe6f4ughlt7APqTSPoTwPRQHghUXwYdL7kv6VthEhDxgCzSsZsIyKUAepvPoe Su4lc8LZrK4L8oFVBzA6ZWeCvVSq/NJRoCjxJMvJxse3N8JH7TOxxt7RLnJG0X02hxk1o59OW+ TeU= Message-ID: Date: Wed, 22 Nov 2023 14:27:55 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-GB From: Andrew Stubbs Subject: [committed] amdgcn: Fix vector TImode reload loop To: "gcc-patches@gcc.gnu.org" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-13.mgc.mentorg.com (139.181.222.13) To svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783274726096531304 X-GMAIL-MSGID: 1783274726096531304 This patch fixes a reload bug that's hard to reproduce reliably (so far I've only observed it on the OG13 branch, with testcase gcc.c-torture/compile/pr70355.c), but causes an infinite loop in reload when it fails. For some reason it wants to save a value from AVGPRs to memory, this can't happen directly on CDNA1, so secondary reload moves the value to VGPRS, but instead of proceeding to memory, LRA just goes and moves the value right back into AVGPRs. Disparaging this move (when a reload is needed) fixes the issue, but I don't know if this is the intended or optimal solution in these cases. Andrew amdgcn: Fix vector TImode reload loop I've only observed the problem on the devel/omp/gcc-13 branch, but this could theoretically affect mainline also. The mov insns for the other modes already have '$', so this completes the set. gcc/ChangeLog: * config/gcn/gcn-valu.md (*mov_4reg): Disparage AVGPR use when a reload is required. diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md index 23f2bbe454b..a928decd408 100644 --- a/gcc/config/gcn/gcn-valu.md +++ b/gcc/config/gcn/gcn-valu.md @@ -566,10 +566,10 @@ (define_insn "*mov_4reg" (match_operand:V_4REG 1 "general_operand"))] "" {@ [cons: =0, 1; attrs: type, length, gcn_version] - [v,vDB;vmult,16,* ] v_mov_b32\t%L0, %L1\; v_mov_b32\t%H0, %H1\; v_mov_b32\t%J0, %J1\; v_mov_b32\t%K0, %K1 - [v,a ;vmult,32,* ] v_accvgpr_read_b32\t%L0, %L1\; v_accvgpr_read_b32\t%H0, %H1\; v_accvgpr_read_b32\t%J0, %J1\; v_accvgpr_read_b32\t%K0, %K1 - [a,v ;vmult,32,* ] v_accvgpr_write_b32\t%L0, %L1\;v_accvgpr_write_b32\t%H0, %H1\;v_accvgpr_write_b32\t%J0, %J1\;v_accvgpr_write_b32\t%K0, %K1 - [a,a ;vmult,32,cdna2] v_accvgpr_mov_b32\t%L0, %L1\; v_accvgpr_mov_b32\t%H0, %H1\; v_accvgpr_mov_b32\t%J0, %J1\; v_accvgpr_mov_b32\t%K0, %K1 + [v ,vDB;vmult,16,* ] v_mov_b32\t%L0, %L1\; v_mov_b32\t%H0, %H1\; v_mov_b32\t%J0, %J1\; v_mov_b32\t%K0, %K1 + [v ,a ;vmult,32,* ] v_accvgpr_read_b32\t%L0, %L1\; v_accvgpr_read_b32\t%H0, %H1\; v_accvgpr_read_b32\t%J0, %J1\; v_accvgpr_read_b32\t%K0, %K1 + [$a,v ;vmult,32,* ] v_accvgpr_write_b32\t%L0, %L1\;v_accvgpr_write_b32\t%H0, %H1\;v_accvgpr_write_b32\t%J0, %J1\;v_accvgpr_write_b32\t%K0, %K1 + [a ,a ;vmult,32,cdna2] v_accvgpr_mov_b32\t%L0, %L1\; v_accvgpr_mov_b32\t%H0, %H1\; v_accvgpr_mov_b32\t%J0, %J1\; v_accvgpr_mov_b32\t%K0, %K1 }) (define_insn "mov_exec"