From patchwork Sun Jun 18 13:20:32 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roger Sayle X-Patchwork-Id: 109615 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp2459590vqr; Sun, 18 Jun 2023 06:21:08 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4Z6EkoAFtI9bou2j/l0NUR3Zkt+fkLhJ/2YcKn3+q0cgrJ2rYkfplNnmVYqh8jkMDYr66e X-Received: by 2002:a17:907:86ac:b0:978:4027:57eb with SMTP id qa44-20020a17090786ac00b00978402757ebmr7526874ejc.47.1687094467492; Sun, 18 Jun 2023 06:21:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687094467; cv=none; d=google.com; s=arc-20160816; b=WFugOVp4DzB+t6ynU21LHPUEoNWp2BS+vQjE4Jkw1wQBlSiCjQTAiTjADIehpwKJRK QTQrEp4YEesGWZVbx9mgBTa3Z0EqatNhchA9g8v34hEfMcMEOdrjp2m/skiybSMi797N VJ7YNp/QguJi6ZbKyB+xXIRgkuBckRARrOggeNYOhakCKToiFOZ1vcIj0ueTebZZdYgF a7t0s5qL1yTTlFyxvf+sghnpfdfda7uqFKxN5Rfi2lDPb8CzPKxfYeL1me+Jyje6C23R ah8D0Kbpg0hQe82NNir6JAEuQPsibFzZQRsQWQuHC/Rinm4ehout5EBUhWJWfYIY9c48 iH6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-language:thread-index :mime-version:message-id:date:subject:to:from:dkim-signature :dmarc-filter:delivered-to; bh=qBmkG86RgqlYCIhjpbPt6f6uH3iIK//ji4HVqKduw2M=; b=YWkw2QEZ//J1OfMRz4d9ps3Z52P1x5fGpEBQFyJUyERAyi0PKF8jM5aceyau86YdLX 1wodRLkbszjovRn9KpsvH6+E4/DkUYOdhWs5xG1ZXCOo634Z32F0T75AxnoaPauRyC6L XjLQZZ6u1/AGRdALyn/gunO42f3Hap1AV3UPjZJjNgOvWSgC/Xd8a6kR2ZO8ErEBfBAd yhNl51j8anXfYe6Zf+lCRdHgx5l53zvjH4zFgV+WGiLZeoikjRotvlqU9DcwgdJaAzZc vbB+VCHUMDLaYhveln/wNF8yLLtO1mCu4R9OnvOxEXuLXaYxeA7pEWJomxDjmW1mPdQo 2Ubw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@nextmovesoftware.com header.s=default header.b="XG/85Vnn"; 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 sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id k17-20020a1709065fd100b00987435d6264si1791086ejv.365.2023.06.18.06.21.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Jun 2023 06:21:07 -0700 (PDT) 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; dkim=fail header.i=@nextmovesoftware.com header.s=default header.b="XG/85Vnn"; 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 B66683858426 for ; Sun, 18 Jun 2023 13:21:00 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from server.nextmovesoftware.com (server.nextmovesoftware.com [162.254.253.69]) by sourceware.org (Postfix) with ESMTPS id 090E93858D28 for ; Sun, 18 Jun 2023 13:20:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 090E93858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nextmovesoftware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nextmovesoftware.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nextmovesoftware.com; s=default; h=Content-Type:MIME-Version:Message-ID: Date:Subject:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=qBmkG86RgqlYCIhjpbPt6f6uH3iIK//ji4HVqKduw2M=; b=XG/85Vnn1eSMKwQlw4NaZz7kBD VNEefbP+55bILODcZlVXvHeUNAMUw28uKkQ/PQBnA/gpBIrLFEdRua3fTmzV2aGl5jheviMeYClVO 8F+9LsO+93oSI4+MwIKR7WstTP9LvGeJcQR8anO4YFSEX8SVjzvkwC9VLzvEUDEOB3vL8NeOpzPgK g+05ZyiDXP0eqQuwqK2bSmIt+rge4n3qEtEs+GFTA7mlmQIqSL+bsZy3s5lg6JqqO1p1VY7ffYPiX THP2eUFApIYwqhTOJpvzZXhwJtMhX+0UkerAD5BGlj8KbsEkCRQPzez+isSIap6OdQ1Cin9/0lr/h hhSzDeBA==; Received: from host86-169-41-81.range86-169.btcentralplus.com ([86.169.41.81]:57045 helo=Dell) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qAsKY-00064W-0u for gcc-patches@gcc.gnu.org; Sun, 18 Jun 2023 09:20:34 -0400 From: "Roger Sayle" To: Subject: [RFC] Workaround LRA reload issue with SUBREGs in SET_DEST. Date: Sun, 18 Jun 2023 14:20:32 +0100 Message-ID: <002001d9a1e7$aa0daac0$fe290040$@nextmovesoftware.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: Admh50WYj56FzpLcQA2rVwJy1l+XTA== Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.nextmovesoftware.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nextmovesoftware.com X-Get-Message-Sender-Via: server.nextmovesoftware.com: authenticated_id: roger@nextmovesoftware.com X-Authenticated-Sender: server.nextmovesoftware.com: roger@nextmovesoftware.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, 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.29 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 Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769046768068953295?= X-GMAIL-MSGID: =?utf-8?q?1769046768068953295?= I was wondering whether I could ask a LRA/reload expert for their help with a better fix with this issue. For the testcase (from sse2-v1ti-mov-1.c): typedef unsigned __int128 uv1ti __attribute__ ((__vector_size__ (16))); uv1ti foo(__int128 x) { return (uv1ti)x; } we currently generate (with -O2) the suboptimal: movq %rdi, %xmm1 movq %rsi, %xmm2 punpcklqdq %xmm2, %xmm1 movdqa %xmm1, %xmm0 Notice that (due to register allocation) the result is calculated in %xmm1 and in the final structure copied to the result %xmm0. With the one line change (workaround) below, we generate the better (optimal) sequence: movq %rdi, %xmm0 movq %rsi, %xmm1 punpcklqdq %xmm1, %xmm0 The triggering event responsible for the current behaviour is that combine merges the two instructions: (insn 12 7 13 2 (set (reg:V2DI 88) (vec_concat:V2DI (reg:DI 95) (reg:DI 96))) "sse2-v1ti-mov-1.c":8:10 discrim 1 7238 {vec_concatv2di} (expr_list:REG_DEAD (reg:DI 96) (expr_list:REG_DEAD (reg:DI 95) (nil)))) (insn 13 12 17 2 (set (reg:V1TI 82 [ ]) (subreg:V1TI (reg:V2DI 88) 0)) "sse2-v1ti-mov-1.c":8:10 discrim 1 1860 {movv1ti_internal} (expr_list:REG_DEAD (reg:V2DI 88) (nil))) into the single instruction (with a SUBREG in the SET_DEST): (insn 13 12 17 2 (set (subreg:V2DI (reg:V1TI 82 [ ]) 0) (vec_concat:V2DI (reg:DI 95) (reg:DI 96))) "sse2-v1ti-mov-1.c":8:10 discrim 1 7244 {vec_concatv2di} (expr_list:REG_DEAD (reg:DI 95) (expr_list:REG_DEAD (reg:DI 96) (nil)))) Unfortunately, this form is challenging for lra/reload... Choosing alt 4 in insn 13: (0) x (1) 0 (2) x {vec_concatv2di} Creating newreg=98, assigning class SSE_REGS to r98 Creating newreg=99 from oldreg=96, assigning class SSE_REGS to r99 13: r98:V2DI=vec_concat(r98:V2DI#0,r99:DI) REG_DEAD r96:DI REG_DEAD r95:DI Inserting insn reload before: 27: clobber r98:V2DI 28: r98:V2DI#0=r95:DI 30: r99:DI=r96:DI Inserting insn reload after: 29: r82:V1TI#0=r98:V2DI It's the clobber of r98 (insn 27) that's generated by the emit_clobber at around line 1081 in match_reload from lra-constraints.cc that's critical, causing r82 and r98 to occupy different registers/allocations. Is there a way of preventing this clobber/conflict? Are V2DI and V1TI correctly annotated as tieable to the same hard register. This patch works by explicitly checking that the destination in vec_concatv2di is a REG_P, i.e. not a SUBREG, and therefore preventing the two instructions to be merged by combine. But clearly this is a case where lra/reload could be doing better. Thoughts? 2023-06-18 Roger Sayle gcc/ChangeLog * config/i386/sse.md (vec_concatv2di): Require that the destination is a REG_P (i.e. a pseudo or hard register, not a SUBREG). Roger diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md index 70d7410..20a26a0 100644 --- a/gcc/config/i386/sse.md +++ b/gcc/config/i386/sse.md @@ -20060,7 +20060,7 @@ " 0, 0,x ,Yv,0,Yv,0,0,v") (match_operand:DI 2 "nonimmediate_operand" " rm,rm,rm,rm,x,Yv,x,m,m")))] - "TARGET_SSE" + "TARGET_SSE && REG_P (operands[0])" "@ pinsrq\t{$1, %2, %0|%0, %2, 1} pinsrq\t{$1, %2, %0|%0, %2, 1}