Message ID | 008401d86d27$d74f9a20$85eece60$@nextmovesoftware.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E678D3825BDA for <patchwork@sourceware.org>; Sat, 21 May 2022 15:31:47 +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 BB4573838034 for <gcc-patches@gcc.gnu.org>; Sat, 21 May 2022 15:31:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BB4573838034 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=rVKBwujWZ/WwiL7I69VbCAcQ5RsvEu7b68YkTaMjB5U=; b=GATsOW1dl2PXSxcP9A9uJs2W3O U3QUYB/BGFFnRrHkSCVdpiAZz+6wtrT2W8STdzPiRO68bUP5i5GNUmSWP6LdZatj5lUikReZUsTnh FmaNNfhtVCtxbYCuYiuND/Nzd9BaQ6HkGdKJsjGnIpiAE019j3tXQTf5Zd3Irg3mIY5dgINrJqJU/ 37f4sdlD/cgCVwfbtfYhjj4WySDk9l7eL/c0BmBBRiFLO/NZyPfLjsYbKy07WK07sHaszcHs0F3b7 YJoN90RUZtGZwaK/RCPg3xuakY5b7N7B7eft0b+OF8Jn6dkNWy84/kSFw5nimjxZLIIQDIAato6Yn P1oqeZuw==; Received: from host109-154-46-241.range109-154.btcentralplus.com ([109.154.46.241]:54446 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 1nsR4j-0007hM-5T for gcc-patches@gcc.gnu.org; Sat, 21 May 2022 11:31:29 -0400 From: "Roger Sayle" <roger@nextmovesoftware.com> To: <gcc-patches@gcc.gnu.org> Subject: [PATCH] Simplify vec_unpack of uniform_vector_p constructors in match.pd. Date: Sat, 21 May 2022 16:31:27 +0100 Message-ID: <008401d86d27$d74f9a20$85eece60$@nextmovesoftware.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0085_01D86D30.39140220" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdhtJi3HiV8h5KyQQQWTwWMbPmTVmg== 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, 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 <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+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
Simplify vec_unpack of uniform_vector_p constructors in match.pd.
|
|
Commit Message
Roger Sayle
May 21, 2022, 3:31 p.m. UTC
This patch simplifies vec_unpack_hi_expr/vec_unpack_lo_expr of a uniform constructor or vec_duplicate operand. The motivation is from PR 105621 where after optimization, we're left with: vect_cst__21 = {c_8(D), c_8(D), c_8(D), c_8(D)}; vect_iftmp.7_4 = [vec_unpack_hi_expr] vect_cst__21; It turns out that there are no constant folding/simplification patterns in match.pd, but the above can be simplified further to the equivalent: _20 = (long int) c_8(D); vect_iftmp.7_4 = [vec_duplicate_expr] _20; which on x86-64 results in one less instruction, replacing pshufd $0 then punpackhq, with punpcklqdq. This transformation is also useful for helping CSE to spot that unpack_hi and unpack_lo are equivalent. This patch has been tested on x86_64-pc-linux-gnu with make bootstrap and make -k check with no new failures. Ok for mainline? 2022-05-21 Roger Sayle <roger@nextmovesoftware.com> gcc/ChangeLog * match.pd (simplify vec_unpack_hi): Simplify VEC_UNPACK_*_EXPR of uniform vector constructors and vec_duplicate. gcc/testsuite/ChangeLog * g++.dg/vect/pr105621.cc: New test case. Thanks in advance, Roger --
Comments
On Sat, May 21, 2022 at 5:31 PM Roger Sayle <roger@nextmovesoftware.com> wrote: > > > This patch simplifies vec_unpack_hi_expr/vec_unpack_lo_expr of a uniform > constructor or vec_duplicate operand. The motivation is from PR 105621 > where after optimization, we're left with: > > vect_cst__21 = {c_8(D), c_8(D), c_8(D), c_8(D)}; > vect_iftmp.7_4 = [vec_unpack_hi_expr] vect_cst__21; > > It turns out that there are no constant folding/simplification patterns > in match.pd, but the above can be simplified further to the equivalent: > > _20 = (long int) c_8(D); > vect_iftmp.7_4 = [vec_duplicate_expr] _20; > > which on x86-64 results in one less instruction, replacing pshufd $0 > then punpackhq, with punpcklqdq. This transformation is also useful > for helping CSE to spot that unpack_hi and unpack_lo are equivalent. > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check with no new failures. Ok for mainline? I think we need a way to query whether the target can do a VEC_DUPLICATE_EXPR. Currently we only ever have them for VL vectors and expand via expand_vector_broadcast which eventually simply gives up when there's no vec_duplicate or vec_init optabs suitable. IIRC with the VEC_PERM extension we should be able to handle VEC_DUPLICATE via VEC_PERM? (but we don't yet accept a scalar input, just V1<mode>?) I see most targets have picked up vec_duplicate but sparc, but still we'd need to check the specific mode. I think we can disregart vec_init checking and only apply the transforms when vec_duplicate is available. Richard. > > 2022-05-21 Roger Sayle <roger@nextmovesoftware.com> > > gcc/ChangeLog > * match.pd (simplify vec_unpack_hi): Simplify VEC_UNPACK_*_EXPR > of uniform vector constructors and vec_duplicate. > > gcc/testsuite/ChangeLog > * g++.dg/vect/pr105621.cc: New test case. > > > Thanks in advance, > Roger > -- >
Richard Biener <richard.guenther@gmail.com> writes: > On Sat, May 21, 2022 at 5:31 PM Roger Sayle <roger@nextmovesoftware.com> wrote: >> This patch simplifies vec_unpack_hi_expr/vec_unpack_lo_expr of a uniform >> constructor or vec_duplicate operand. The motivation is from PR 105621 >> where after optimization, we're left with: >> >> vect_cst__21 = {c_8(D), c_8(D), c_8(D), c_8(D)}; >> vect_iftmp.7_4 = [vec_unpack_hi_expr] vect_cst__21; >> >> It turns out that there are no constant folding/simplification patterns >> in match.pd, but the above can be simplified further to the equivalent: >> >> _20 = (long int) c_8(D); >> vect_iftmp.7_4 = [vec_duplicate_expr] _20; >> >> which on x86-64 results in one less instruction, replacing pshufd $0 >> then punpackhq, with punpcklqdq. This transformation is also useful >> for helping CSE to spot that unpack_hi and unpack_lo are equivalent. >> >> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap >> and make -k check with no new failures. Ok for mainline? > > I think we need a way to query whether the target can do a VEC_DUPLICATE_EXPR. > Currently we only ever have them for VL vectors and expand via > expand_vector_broadcast which eventually simply gives up when there's no > vec_duplicate or vec_init optabs suitable. > > IIRC with the VEC_PERM extension we should be able to handle > VEC_DUPLICATE via VEC_PERM? (but we don't yet accept a scalar > input, just V1<mode>?) Yeah, should be possible. Not sure whether it would really help though. A VEC_PERM_EXPR with only one scalar argument could only have one sensible permute mask[*], so there'd be a bit of false generality. Maybe allowing scalar arguments would be more useful for 2 distinct scalar arguments, but then I guess the question is: why stop at 2? So if we go down the route of accepting scalars, it might be more consistent to make VEC_PERM_EXPR support any number of operands and use it as a replacement for CONSTRUCTOR as well. Thanks, Richard [*] At least until we support “don't care” elements. However, like I mentioned before, I'd personally prefer a “don't care” mask to be a separate operand, rather than treating something like -1 as a special value. Special values like that don't really fit the current encoding scheme for VL constants, but a separate mask would. A separate don't-care mask would also work for variable permute masks. > > I see most targets have picked up vec_duplicate but sparc, but still > we'd need to check the specific mode. I think we can disregart > vec_init checking and only apply the transforms when vec_duplicate > is available. > > Richard. > >> >> 2022-05-21 Roger Sayle <roger@nextmovesoftware.com> >> >> gcc/ChangeLog >> * match.pd (simplify vec_unpack_hi): Simplify VEC_UNPACK_*_EXPR >> of uniform vector constructors and vec_duplicate. >> >> gcc/testsuite/ChangeLog >> * g++.dg/vect/pr105621.cc: New test case. >> >> >> Thanks in advance, >> Roger >> -- >>
On Mon, Jun 6, 2022 at 11:06 AM Richard Sandiford <richard.sandiford@arm.com> wrote: > > Richard Biener <richard.guenther@gmail.com> writes: > > On Sat, May 21, 2022 at 5:31 PM Roger Sayle <roger@nextmovesoftware.com> wrote: > >> This patch simplifies vec_unpack_hi_expr/vec_unpack_lo_expr of a uniform > >> constructor or vec_duplicate operand. The motivation is from PR 105621 > >> where after optimization, we're left with: > >> > >> vect_cst__21 = {c_8(D), c_8(D), c_8(D), c_8(D)}; > >> vect_iftmp.7_4 = [vec_unpack_hi_expr] vect_cst__21; > >> > >> It turns out that there are no constant folding/simplification patterns > >> in match.pd, but the above can be simplified further to the equivalent: > >> > >> _20 = (long int) c_8(D); > >> vect_iftmp.7_4 = [vec_duplicate_expr] _20; > >> > >> which on x86-64 results in one less instruction, replacing pshufd $0 > >> then punpackhq, with punpcklqdq. This transformation is also useful > >> for helping CSE to spot that unpack_hi and unpack_lo are equivalent. > >> > >> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > >> and make -k check with no new failures. Ok for mainline? > > > > I think we need a way to query whether the target can do a VEC_DUPLICATE_EXPR. > > Currently we only ever have them for VL vectors and expand via > > expand_vector_broadcast which eventually simply gives up when there's no > > vec_duplicate or vec_init optabs suitable. > > > > IIRC with the VEC_PERM extension we should be able to handle > > VEC_DUPLICATE via VEC_PERM? (but we don't yet accept a scalar > > input, just V1<mode>?) > > Yeah, should be possible. Not sure whether it would really help though. > A VEC_PERM_EXPR with only one scalar argument could only have one sensible > permute mask[*], so there'd be a bit of false generality. > > Maybe allowing scalar arguments would be more useful for 2 distinct > scalar arguments, but then I guess the question is: why stop at 2? > So if we go down the route of accepting scalars, it might be more > consistent to make VEC_PERM_EXPR support any number of operands > and use it as a replacement for CONSTRUCTOR as well. Discussion was hijacked by the '[PATCH]AArch64 relax predicate on load structure load instructions' thread btw. Roger - your eyesopen.com mail bounces, can you fix your MAINTAINERS entry please? Richard. > Thanks, > Richard > > [*] At least until we support “don't care” elements. However, like I > mentioned before, I'd personally prefer a “don't care” mask to be > a separate operand, rather than treating something like -1 as a > special value. Special values like that don't really fit the > current encoding scheme for VL constants, but a separate mask would. > > A separate don't-care mask would also work for variable permute masks. > > > > I see most targets have picked up vec_duplicate but sparc, but still > > we'd need to check the specific mode. I think we can disregart > > vec_init checking and only apply the transforms when vec_duplicate > > is available. > > > > Richard. > > > >> > >> 2022-05-21 Roger Sayle <roger@nextmovesoftware.com> > >> > >> gcc/ChangeLog > >> * match.pd (simplify vec_unpack_hi): Simplify VEC_UNPACK_*_EXPR > >> of uniform vector constructors and vec_duplicate. > >> > >> gcc/testsuite/ChangeLog > >> * g++.dg/vect/pr105621.cc: New test case. > >> > >> > >> Thanks in advance, > >> Roger > >> -- > >>
diff --git a/gcc/match.pd b/gcc/match.pd index c2fed9b..753c392 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -7800,6 +7800,22 @@ and, (if (TREE_CODE (@0) == SSA_NAME && num_imm_uses (@0) == 2) (minus (mult (vec_perm @1 @1 @3) @2) @4))) +/* VEC_UNPACK_LO_EXPR and friends. */ +(for unpack (vec_unpack_lo vec_unpack_float_lo vec_unpack_fix_trunc_lo + vec_unpack_hi vec_unpack_float_hi vec_unpack_fix_trunc_hi) + opcode (convert float fix_trunc convert float fix_trunc) + (simplify + (unpack CONSTRUCTOR@0) + (with { tree ctor = (TREE_CODE (@0) == SSA_NAME + ? gimple_assign_rhs1 (SSA_NAME_DEF_STMT (@0)) : @0); + tree elt = uniform_vector_p (ctor); + tree eltype = TREE_TYPE (type); } + (if (elt) + (vec_duplicate (opcode:eltype { elt; }))))) + (simplify + (unpack (vec_duplicate @0)) + (with { tree eltype = TREE_TYPE (type); } + (vec_duplicate (opcode:eltype @0))))) /* Match count trailing zeroes for simplify_count_trailing_zeroes in fwprop. The canonical form is array[((x & -x) * C) >> SHIFT] where C is a magic diff --git a/gcc/testsuite/g++.dg/vect/pr105621.cc b/gcc/testsuite/g++.dg/vect/pr105621.cc new file mode 100644 index 0000000..98e8fcd --- /dev/null +++ b/gcc/testsuite/g++.dg/vect/pr105621.cc @@ -0,0 +1,11 @@ +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-optimized" } */ + +bool d; + +void test(unsigned short a, int b, unsigned c) { + for (int i = 2; i < 24; i += 3) + d = b ? a ? c : 2086607777901731118 : 0; +} + +/* { dg-final { scan-tree-dump-not "vec_unpack" "optimized" } } */