From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server.nextmovesoftware.com (server.nextmovesoftware.com [162.254.253.69]) by sourceware.org (Postfix) with ESMTPS id EE72C385802D for ; Fri, 15 Oct 2021 12:15:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EE72C385802D 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:Cc:To:From:Sender:Reply-To: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=WSHmHTgQa4LihRBz29xMGLg05uj4/3FR3yonZ26WQQ4=; b=sfoquP5hiBldtNFc3vRwFpE7cD rhQXVn8nAX6Qh4DgFCH+3Xlby1KrCoeFuarlgngMp/d2WvBdxZGZq8zpYOhgznYHSh1Qx/kQwYzke RgAHykbiKYew2yi04ivSc43wAHAe0EK7+DVtUe6Ax6VbDm9Ru9BUdTHvNOEZZZgixQsjakurTdRMJ jc1HtYk/XyNt1Oo3QchIDkOpkVgxLb23eyJEWZZu3uXJz56Knf/NtVUg1EROjOAL8B7T4elepdr3w 1UFbwy2e6crmmpviWnIgT7dvDoY5vHs3DaaZqXisyPK/VVuIFHmik0MeX2TSig2REAp9h5Kdc+9eO SZm4E6GA==; Received: from [185.62.158.67] (port=61438 helo=Dell) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mbM7x-0001iU-89; Fri, 15 Oct 2021 08:15:57 -0400 From: "Roger Sayle" To: "'GCC Patches'" Subject: [PATCH] Allow early sets of SSE hard registers from standard_sse_constant_p Date: Fri, 15 Oct 2021 13:15:56 +0100 Message-ID: <002c01d7c1be$689d3840$39d7a8c0$@nextmovesoftware.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002D_01D7C1C6.CA61A040" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdfBvHhbEG7ZfFIKSyS7+iFAt2VRLQ== 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=-12.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: , X-List-Received-Date: Fri, 15 Oct 2021 12:16:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002D_01D7C1C6.CA61A040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My previous patch, which was intended to reduce the differences seen by the combination of -march=cascadelake and -m32, has additionally found some more instances where this combination behaves differently to regular x86_64-pc-linux-gnu. The middle-end always, and backends usually, use emit_move_insn to emit/expand move instructions allowing the backend control over placing things in constant pools, adding REG_EQUAL notes, and so on. Several of the AVX512 built-in expanders bypass this logic, and instead generate moves directly using emit_insn(gen_rtx_SET (dst,src)). For example, i386-expand.c line 12004 contains: for (i = 0; i < 8; i++) emit_insn (gen_rtx_SET (xmm_regs[i], const0_rtx)); I suspect that in this case, loading of standard_sse_constant_p, my change to require loading of likely spilled hard registers via a pseudo is perhaps overly strict, so this patch/fix reallows these immediate constants values to be loaded directly prior to reload. If anyone notices a (SPEC benchmark) performance regression with this patch, I'll propose the more invasive fix to make more use of emit_move_insn in the backend (and revert this fix), but all things being equal it's best to leave things the way they previously were. This patch not only cures the regressions reported by Sunil's tester, but in combination with the previous patch now has 7 fewer unexpected failures in the testsuite with -m32 -march=cascadelake. This patch has also been tested with "make bootstrap" and "make -k check" on x86_64-pc-linux-gnu with no new failures. Ok for mainline? Sorry again for the temporary inconvenience. 2021-10-15 Roger Sayle gcc/ChangeLog * config/i386/i386.c (ix86_hardreg_mov_ok): For vector modes, allow standard_sse_constant_p immediate constants. Thanks in advance, Roger -- ------=_NextPart_000_002D_01D7C1C6.CA61A040 Content-Type: text/plain; name="patchv4b.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patchv4b.txt" diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c=0A= index fb65609..9cc903e 100644=0A= --- a/gcc/config/i386/i386.c=0A= +++ b/gcc/config/i386/i386.c=0A= @@ -19303,7 +19303,9 @@ ix86_hardreg_mov_ok (rtx dst, rtx src)=0A= /* Avoid complex sets of likely_spilled hard registers before reload. = */=0A= if (REG_P (dst) && HARD_REGISTER_P (dst)=0A= && !REG_P (src) && !MEM_P (src)=0A= - && !x86_64_immediate_operand (src, GET_MODE (dst))=0A= + && !(VECTOR_MODE_P (GET_MODE (dst))=0A= + ? standard_sse_constant_p (src, GET_MODE (dst))=0A= + : x86_64_immediate_operand (src, GET_MODE (dst)))=0A= && ix86_class_likely_spilled_p (REGNO_REG_CLASS (REGNO (dst)))=0A= && !reload_completed)=0A= return false;=0A= ------=_NextPart_000_002D_01D7C1C6.CA61A040--