Message ID | 01fd01d8a5ac$bfe5dc60$3fb19520$@nextmovesoftware.com |
---|---|
State | New, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6a10:b5d6:b0:2b9:3548:2db5 with SMTP id v22csp2346149pxt; Mon, 1 Aug 2022 06:44:30 -0700 (PDT) X-Google-Smtp-Source: AGRyM1ss04yjx0VB/12XawVLUQ+p6jpPwzT2Z7WwV8RCjH4XM4kSZvX+H9x53nPHVzv9KpRz2uC2 X-Received: by 2002:a17:906:93e8:b0:72b:6923:a0b9 with SMTP id yl8-20020a17090693e800b0072b6923a0b9mr12216329ejb.244.1659361469826; Mon, 01 Aug 2022 06:44:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659361469; cv=none; d=google.com; s=arc-20160816; b=OvRLGdSxczhZ0N8VAwzSVWv/L1yqesj0EavMLQrDTuTOtsuqVbmKIbVpkbZqquQJ9x RgXfuPJWvCwvtP4D6Je++E7AVv3zc+BJrWXn43c4Ys6692OEhOBZGZ2pc4a4HsCjHmpW 8DNyADRLlPG2u6MV9ttDr8v0mCapSj+Y8ARkDUV39h5ucddYIvRuBe0a5dyZHw7XnZBx /BgfOTdvOQHSOZxL55OPEinMSQxT7Jk2BTYLiBKoD43u8alSLPZ7/QSWaC8z6qK9aBkV ql57u5hlwKKLM/IRbUuN2zIhcAM5KtwUFuFUvKEfNPh04PtUy0DkGgeDSuKqa5qDT+ch KiaQ== 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=oo5iyc3fj/LS0Z+o6foxYzgSjxIp6ag2HrDla/vXzrA=; b=Iw4E5k9FFKQflwY5FLsULQJjFoIh+SS8qs5PZzBvKvC+SgvtasF+S/9S2QCqUlKj5G vS7oZ9n5RNxSkJG5TJ7vp2ElZtDKetHWvT7LY/Df8SYlkXcwZKr1e6MPGXOgcPfz/dW0 fE9YJ6gWr+xOyI08jS96aDuXwx1NrXRfx4uaKmgv92ATnya4TwdkQGesm1tuY+/lkbHI ZnSbbwBc/K9pW0+UinFRZlG42+9mYr6Qj3pANBD0SfKG2sT/9aNHkP/kBZ2TpI5rI4Cc 6GJudKT5UbLYWkh2lFV1VumU/XvoMJe+5NmYkMKYwlX72Bnaaj5KHH1+ig2+KtSB1JYM Ne/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@nextmovesoftware.com header.s=default header.b=CbdB8UoR; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org" Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id qw17-20020a1709066a1100b0072b3bc0d215si11393816ejc.149.2022.08.01.06.44.29 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Aug 2022 06:44:29 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=fail header.i=@nextmovesoftware.com header.s=default header.b=CbdB8UoR; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c 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 058953858000 for <ouuuleilei@gmail.com>; Mon, 1 Aug 2022 13:44:23 +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 63DBA3858D39 for <gcc-patches@gcc.gnu.org>; Mon, 1 Aug 2022 13:43:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 63DBA3858D39 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=oo5iyc3fj/LS0Z+o6foxYzgSjxIp6ag2HrDla/vXzrA=; b=CbdB8UoRjminAeV5yIqxopL9Ar rInmZuhkAlYqv482XKWavg417Y3BOwE0KO9Wx0d5MJ+sBYEJJ+XXCUMC8Tk4EAJjDSELv2jvALH8a 03gGGzU+s/BUdzfBsCzFL2ZeZgwYPpKMwTP1kv83M8rVBW5t4nttcVBocWu0w9YDR4uFnTwi4QNQX o6eRtRflpZNOEbYtIPMcEZy1n37zyY2RrS9RvvUyTU3N4FmUDDdpK3frrWMkTzdAs4a70D2s10IHH r47PgBvwu1d5sfHYaKcOVyzlhe6BgAR7gKIwnVOhCdK4mmsYKoKbbSVOqA8Gx8LCp+U6C6rgTw2pE sz9rElKA==; Received: from [185.62.158.67] (port=58119 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 <roger@nextmovesoftware.com>) id 1oIViA-0003cF-IK; Mon, 01 Aug 2022 09:43:58 -0400 From: "Roger Sayle" <roger@nextmovesoftware.com> To: "'GCC Patches'" <gcc-patches@gcc.gnu.org> Subject: [x86_64 PATCH] PR target/106481: Handle CONST_WIDE_INT in REG_EQUAL during STV. Date: Mon, 1 Aug 2022 14:43:56 +0100 Message-ID: <01fd01d8a5ac$bfe5dc60$3fb19520$@nextmovesoftware.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01FE_01D8A5B5.21AB55D0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: Adilq8IJHKg2Ts+rToGOKkMWH9ODsg== 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.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1739966612597203241?= X-GMAIL-MSGID: =?utf-8?q?1739966612597203241?= |
Series |
[x86_64] PR target/106481: Handle CONST_WIDE_INT in REG_EQUAL during STV.
|
|
Commit Message
Roger Sayle
Aug. 1, 2022, 1:43 p.m. UTC
This patch resolves PR target/106481, and is an oversight in my recent battles with REG_EQUAL notes during TImode STV (see PR target/106278 https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598416.html). The patch above's/current behaviour is that we check that the mode of the REG_EQUAL note is TImode before using PUT_MODE to set it to V1TImode. However, the new test case reveals that this doesn't consider REG_EQUAL notes that are CONST_INT or CONST_WIDE_INT, i.e. that are VOIDmode, and so STV produces: (insn 85 84 86 2 (set (reg:V1TI 113) (reg:V1TI 84)) "pr106481.c":13:3 1766 {movv1ti_internal} (expr_list:REG_EQUAL (const_wide_int 0x0ffffffff00000004) (nil))) which causes problems as the const_wide_int isn't a valid immediate constant for V1TImode. With this patch, we now generate the correct: (insn 85 84 86 2 (set (reg:V1TI 113) (reg:V1TI 84)) "pr106481.c":13:3 1766 {movv1ti_internal} (expr_list:REG_EQUAL (const_vector:V1TI [ (const_wide_int 0x0ffffffff00000004) ]) (nil))) This patch has been tested on x86_64-pc-linux-gnu with make bootstrap and make -k check, both with and without --target_board=unix{-m32}, with no new failures. Ok for mainline? 2022-08-01 Roger Sayle <roger@nextmovesoftware.com> gcc/ChangeLog PR target/106481 * config/i386/i386-features.cc (timode_scalar_chain::convert_insn): Convert a CONST_SCALAR_INT_P in a REG_EQUAL note into a V1TImode CONST_VECTOR. gcc/testsuite/ChangeLog PR target/106481 * gcc.target/i386/pr106481.c: New test case. Thanks again, Roger --
Comments
On Mon, Aug 1, 2022 at 3:43 PM Roger Sayle <roger@nextmovesoftware.com> wrote: > > > This patch resolves PR target/106481, and is an oversight in my recent > battles with REG_EQUAL notes during TImode STV (see PR target/106278 > https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598416.html). > > The patch above's/current behaviour is that we check that the mode of > the REG_EQUAL note is TImode before using PUT_MODE to set it to V1TImode. > However, the new test case reveals that this doesn't consider REG_EQUAL > notes that are CONST_INT or CONST_WIDE_INT, i.e. that are VOIDmode, > and so STV produces: > > (insn 85 84 86 2 (set (reg:V1TI 113) > (reg:V1TI 84)) "pr106481.c":13:3 1766 {movv1ti_internal} > (expr_list:REG_EQUAL (const_wide_int 0x0ffffffff00000004) > (nil))) > > which causes problems as the const_wide_int isn't a valid immediate > constant for V1TImode. With this patch, we now generate the correct: > > (insn 85 84 86 2 (set (reg:V1TI 113) > (reg:V1TI 84)) "pr106481.c":13:3 1766 {movv1ti_internal} > (expr_list:REG_EQUAL (const_vector:V1TI [ > (const_wide_int 0x0ffffffff00000004) > ]) > (nil))) > > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check, both with and without --target_board=unix{-m32}, > with no new failures. Ok for mainline? > > > 2022-08-01 Roger Sayle <roger@nextmovesoftware.com> > > gcc/ChangeLog > PR target/106481 > * config/i386/i386-features.cc (timode_scalar_chain::convert_insn): > Convert a CONST_SCALAR_INT_P in a REG_EQUAL note into a V1TImode > CONST_VECTOR. > > gcc/testsuite/ChangeLog > PR target/106481 > * gcc.target/i386/pr106481.c: New test case. OK, but how about we restructure the conditions a bit, like in the attached patch? Uros. diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc index e4cc4a30590..e3ecc22580a 100644 --- a/gcc/config/i386/i386-features.cc +++ b/gcc/config/i386/i386-features.cc @@ -1353,8 +1353,15 @@ timode_scalar_chain::convert_insn (rtx_insn *insn) if (GET_MODE (dst) == V1TImode) { tmp = find_reg_equal_equiv_note (insn); - if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode) - PUT_MODE (XEXP (tmp, 0), V1TImode); + if (tmp) + { + if (GET_MODE (XEXP (tmp, 0)) == TImode) + PUT_MODE (XEXP (tmp, 0), V1TImode); + else if (CONST_SCALAR_INT_P (XEXP (tmp, 0))) + XEXP (tmp, 0) + = gen_rtx_CONST_VECTOR (V1TImode, + gen_rtvec (1, XEXP (tmp, 0))); + } } break; case MEM:
diff --git a/gcc/config/i386/i386-features.cc b/gcc/config/i386/i386-features.cc index aa5de71..c1564c4 100644 --- a/gcc/config/i386/i386-features.cc +++ b/gcc/config/i386/i386-features.cc @@ -1355,6 +1355,10 @@ timode_scalar_chain::convert_insn (rtx_insn *insn) tmp = find_reg_equal_equiv_note (insn); if (tmp && GET_MODE (XEXP (tmp, 0)) == TImode) PUT_MODE (XEXP (tmp, 0), V1TImode); + else if (tmp && CONST_SCALAR_INT_P (XEXP (tmp, 0))) + XEXP (tmp, 0) = gen_rtx_CONST_VECTOR (V1TImode, + gen_rtvec (1, + XEXP (tmp, 0))); } break; case MEM: diff --git a/gcc/testsuite/gcc.target/i386/pr106481.c b/gcc/testsuite/gcc.target/i386/pr106481.c new file mode 100644 index 0000000..8cc7048 --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/pr106481.c @@ -0,0 +1,17 @@ +/* { dg-do compile { target int128 } } */ +/* { dg-options "-O2 -fno-dce -fno-forward-propagate -fno-rerun-cse-after-loop -Wno-psabi" } */ + +typedef int V __attribute__((vector_size (64))); +typedef __int128 W __attribute__((vector_size (64))); + +W w; +V bar (void); + +void +foo (V v, W) +{ + foo ((V){4, ~0}, (W) v); + foo (v, w); + bar (); +} +