From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by sourceware.org (Postfix) with ESMTPS id CF6F93857BAD for ; Mon, 13 Jun 2022 09:53:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CF6F93857BAD Received: by mail-qk1-x736.google.com with SMTP id x75so3607639qkb.12 for ; Mon, 13 Jun 2022 02:53:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=85wZGl7hEcCoNeRI3qaBJ00WnI437B37iLxMp03ZdI4=; b=zxIWpXjQIgE4LC95voankH6Ck54kv4chUQ1cbu6XGz9nonrA8XbQXRtefZkajqql0X 4SQKUTwqWeKg08R0Vsn3RYEVdz4tmrX4hUHXGyQE5C1Sd7cGzDUswzN3xFLOUBRhdfqF 4klxKGdjz7sp3oSFhgUT4JL51aBAaODQsGE+LKBauhaAgr3n17qY13rbPHMYkxLJ+Xjt G2f/f5azgCj0p/LVSYUwAjXZHWa51eyhezDZVKaL0Skji/4auaGjc9i+0jZ67F4feSTA J659l+km2H4u89tp2y4t9hHWSF/vncj4J1OORViQKW0Zq90J61XchsO9SGITd4f4R3n4 gAsw== X-Gm-Message-State: AOAM5300/88aP884wFgdT2LMUNIvWMKDLDPr2gQRePAXJAAb3oYJJG7f pSz1jRZ9PXAQGx7qMigPK9sX+ONXiOK93cEcPbIkNTHxwlDt+g== X-Google-Smtp-Source: ABdhPJxokReqEJQsxiWEOB5R44D6X4hzt9HiLGJP+k6PO2KxZvZN+yZ9CeGmvzR2SValScLPrgG+tHtz7S6/x7gPO4E= X-Received: by 2002:a05:620a:16d4:b0:6a6:b1cd:4f71 with SMTP id a20-20020a05620a16d400b006a6b1cd4f71mr28564634qkn.581.1655113990140; Mon, 13 Jun 2022 02:53:10 -0700 (PDT) MIME-Version: 1.0 References: <008401d86d27$d74f9a20$85eece60$@nextmovesoftware.com> In-Reply-To: From: Richard Biener Date: Mon, 13 Jun 2022 11:52:58 +0200 Message-ID: Subject: Re: [PATCH] Simplify vec_unpack of uniform_vector_p constructors in match.pd. To: Richard Biener , Roger Sayle , GCC Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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: , X-List-Received-Date: Mon, 13 Jun 2022 09:53:14 -0000 On Mon, Jun 6, 2022 at 11:06 AM Richard Sandiford wrote: > > Richard Biener writes: > > On Sat, May 21, 2022 at 5:31 PM Roger Sayle wrote: > >> This patch simplifies vec_unpack_hi_expr/vec_unpack_lo_expr of a unifo= rm > >> constructor or vec_duplicate operand. The motivation is from PR 10562= 1 > >> where after optimization, we're left with: > >> > >> vect_cst__21 =3D {c_8(D), c_8(D), c_8(D), c_8(D)}; > >> vect_iftmp.7_4 =3D [vec_unpack_hi_expr] vect_cst__21; > >> > >> It turns out that there are no constant folding/simplification pattern= s > >> in match.pd, but the above can be simplified further to the equivalent= : > >> > >> _20 =3D (long int) c_8(D); > >> vect_iftmp.7_4 =3D [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_DUPLICAT= E_EXPR. > > Currently we only ever have them for VL vectors and expand via > > expand_vector_broadcast which eventually simply gives up when there's n= o > > 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?) > > 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 sensibl= e > 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 =E2=80=9Cdon't care=E2=80=9D elements. How= ever, like I > mentioned before, I'd personally prefer a =E2=80=9Cdon't care=E2=80= =9D 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 > >> > >> gcc/ChangeLog > >> * match.pd (simplify vec_unpack_hi): Simplify VEC_UNPACK_*_EXP= R > >> of uniform vector constructors and vec_duplicate. > >> > >> gcc/testsuite/ChangeLog > >> * g++.dg/vect/pr105621.cc: New test case. > >> > >> > >> Thanks in advance, > >> Roger > >> -- > >>