From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 72A5D3858C74 for ; Thu, 11 Aug 2022 13:23:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 72A5D3858C74 Received: by mail-ej1-x636.google.com with SMTP id w19so33500704ejc.7 for ; Thu, 11 Aug 2022 06:23:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=bfOnj1xD1PJFxYl4+yJj5hm916l999hZGpKHW/Lhp9g=; b=D33a3kkwTCUtzV9HXqG+Zt8AzRK5olUDzGiAwbhGSu67c7bLC/xDjro7fGsnbKPHNl DW7dyCFTuZaDX0kTcH0FUiHM/cMs3tAQ8VoIcEEBaL+XxKXA2SruJIN0jUMWzk/V8WZ/ u6JLZ02HHvWsLQp9AKcUyAHocNNSwIdHNLOgkLCcZVZFniHC2gktWvRsEWA4gxccX0uh KVGRGna8oMgTUlWq55WzJBptJbe0vqFHQ6xvoMKfP8Ktentw0vneB8FKtrrF5NGgUUE1 2TR96g4lk8NBc9QLRe0rWF7uvsePCPRxinpJ4dgwFhg6U/Xue+ez0c9k5qtKCpQyHbQE XQ1w== X-Gm-Message-State: ACgBeo1t+IQcIlycS7vsHsbqcrf4zCwaLiQXxLvDMcawZBgChk7/X5bs AYNhksL8+oJU07C25Ve5PFvD2MsmlNXFbhNOdqJYFQ== X-Google-Smtp-Source: AA6agR4waWgru8smwC8SaIOqU4ypT+Ep/adUOntmuUpHqMV7sQv+FA4AnXDlE/yaLWFhvbpAtpnsnYRP42TJBwZlBME= X-Received: by 2002:a17:907:60c7:b0:731:148b:c515 with SMTP id hv7-20020a17090760c700b00731148bc515mr19335913ejc.724.1660224227890; Thu, 11 Aug 2022 06:23:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Prathamesh Kulkarni Date: Thu, 11 Aug 2022 18:53:11 +0530 Message-ID: Subject: Re: ICE after folding svld1rq to vec_perm_expr duing forwprop To: Richard Biener Cc: gcc Patches , Richard Sandiford Content-Type: multipart/mixed; boundary="0000000000005a0fc605e5f71397" X-Spam-Status: No, score=-8.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SCC_5_SHORT_WORD_LINES, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, WEIRD_PORT 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: Thu, 11 Aug 2022 13:23:53 -0000 --0000000000005a0fc605e5f71397 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 9 Aug 2022 at 18:42, Richard Biener wr= ote: > > On Tue, Aug 9, 2022 at 12:10 PM Prathamesh Kulkarni > wrote: > > > > On Mon, 8 Aug 2022 at 14:27, Richard Biener wrote: > > > > > > On Mon, Aug 1, 2022 at 5:17 AM Prathamesh Kulkarni > > > wrote: > > > > > > > > On Thu, 21 Jul 2022 at 12:21, Richard Biener wrote: > > > > > > > > > > On Wed, Jul 20, 2022 at 5:36 PM Prathamesh Kulkarni > > > > > wrote: > > > > > > > > > > > > On Mon, 18 Jul 2022 at 11:57, Richard Biener wrote: > > > > > > > > > > > > > > On Fri, Jul 15, 2022 at 3:49 PM Prathamesh Kulkarni > > > > > > > wrote: > > > > > > > > > > > > > > > > On Thu, 14 Jul 2022 at 17:22, Richard Sandiford > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Richard Biener writes: > > > > > > > > > > On Thu, Jul 14, 2022 at 9:55 AM Prathamesh Kulkarni > > > > > > > > > > wrote: > > > > > > > > > >> > > > > > > > > > >> On Wed, 13 Jul 2022 at 12:22, Richard Biener wrote: > > > > > > > > > >> > > > > > > > > > > >> > On Tue, Jul 12, 2022 at 9:12 PM Prathamesh Kulkarni = via Gcc-patches > > > > > > > > > >> > wrote: > > > > > > > > > >> > > > > > > > > > > > >> > > Hi Richard, > > > > > > > > > >> > > For the following test: > > > > > > > > > >> > > > > > > > > > > > >> > > svint32_t f2(int a, int b, int c, int d) > > > > > > > > > >> > > { > > > > > > > > > >> > > int32x4_t v =3D (int32x4_t) {a, b, c, d}; > > > > > > > > > >> > > return svld1rq_s32 (svptrue_b8 (), &v[0]); > > > > > > > > > >> > > } > > > > > > > > > >> > > > > > > > > > > > >> > > The compiler emits following ICE with -O3 -mcpu=3D= generic+sve: > > > > > > > > > >> > > foo.c: In function =E2=80=98f2=E2=80=99: > > > > > > > > > >> > > foo.c:4:11: error: non-trivial conversion in =E2= =80=98view_convert_expr=E2=80=99 > > > > > > > > > >> > > 4 | svint32_t f2(int a, int b, int c, int d) > > > > > > > > > >> > > | ^~ > > > > > > > > > >> > > svint32_t > > > > > > > > > >> > > __Int32x4_t > > > > > > > > > >> > > _7 =3D VIEW_CONVERT_EXPR<__Int32x4_t>(_8); > > > > > > > > > >> > > during GIMPLE pass: forwprop > > > > > > > > > >> > > dump file: foo.c.109t.forwprop2 > > > > > > > > > >> > > foo.c:4:11: internal compiler error: verify_gimple= failed > > > > > > > > > >> > > 0xfda04a verify_gimple_in_cfg(function*, bool) > > > > > > > > > >> > > ../../gcc/gcc/tree-cfg.cc:5568 > > > > > > > > > >> > > 0xe9371f execute_function_todo > > > > > > > > > >> > > ../../gcc/gcc/passes.cc:2091 > > > > > > > > > >> > > 0xe93ccb execute_todo > > > > > > > > > >> > > ../../gcc/gcc/passes.cc:2145 > > > > > > > > > >> > > > > > > > > > > > >> > > This happens because, after folding svld1rq_s32 to= vec_perm_expr, we have: > > > > > > > > > >> > > int32x4_t v; > > > > > > > > > >> > > __Int32x4_t _1; > > > > > > > > > >> > > svint32_t _9; > > > > > > > > > >> > > vector(4) int _11; > > > > > > > > > >> > > > > > > > > > > > >> > > : > > > > > > > > > >> > > _1 =3D {a_3(D), b_4(D), c_5(D), d_6(D)}; > > > > > > > > > >> > > v_12 =3D _1; > > > > > > > > > >> > > _11 =3D v_12; > > > > > > > > > >> > > _9 =3D VEC_PERM_EXPR <_11, _11, { 0, 1, 2, 3, ..= . }>; > > > > > > > > > >> > > return _9; > > > > > > > > > >> > > > > > > > > > > > >> > > During forwprop, simplify_permutation simplifies v= ec_perm_expr to > > > > > > > > > >> > > view_convert_expr, > > > > > > > > > >> > > and the end result becomes: > > > > > > > > > >> > > svint32_t _7; > > > > > > > > > >> > > __Int32x4_t _8; > > > > > > > > > >> > > > > > > > > > > > >> > > ;; basic block 2, loop depth 0 > > > > > > > > > >> > > ;; pred: ENTRY > > > > > > > > > >> > > _8 =3D {a_2(D), b_3(D), c_4(D), d_5(D)}; > > > > > > > > > >> > > _7 =3D VIEW_CONVERT_EXPR<__Int32x4_t>(_8); > > > > > > > > > >> > > return _7; > > > > > > > > > >> > > ;; succ: EXIT > > > > > > > > > >> > > > > > > > > > > > >> > > which causes the error duing verify_gimple since V= IEW_CONVERT_EXPR > > > > > > > > > >> > > has incompatible types (svint32_t, int32x4_t). > > > > > > > > > >> > > > > > > > > > > > >> > > The attached patch disables simplification of VEC_= PERM_EXPR > > > > > > > > > >> > > in simplify_permutation, if lhs and rhs have non c= ompatible types, > > > > > > > > > >> > > which resolves ICE, but am not sure if it's the co= rrect approach ? > > > > > > > > > >> > > > > > > > > > > >> > It for sure papers over the issue. I think the erro= r happens earlier, > > > > > > > > > >> > the V_C_E should have been built with the type of th= e VEC_PERM_EXPR > > > > > > > > > >> > which is the type of the LHS. But then you probably= run into the > > > > > > > > > >> > different sizes ICE (VLA vs constant size). I think= for this case you > > > > > > > > > >> > want a BIT_FIELD_REF instead of a VIEW_CONVERT_EXPR, > > > > > > > > > >> > selecting the "low" part of the VLA vector. > > > > > > > > > >> Hi Richard, > > > > > > > > > >> Sorry I don't quite follow. In this case, we use VEC_P= ERM_EXPR to > > > > > > > > > >> represent dup operation > > > > > > > > > >> from fixed width to VLA vector. I am not sure how fold= ing it to > > > > > > > > > >> BIT_FIELD_REF will work. > > > > > > > > > >> Could you please elaborate ? > > > > > > > > > >> > > > > > > > > > >> Also, the issue doesn't seem restricted to this case. > > > > > > > > > >> The following test case also ICE's during forwprop: > > > > > > > > > >> svint32_t foo() > > > > > > > > > >> { > > > > > > > > > >> int32x4_t v =3D (int32x4_t) {1, 2, 3, 4}; > > > > > > > > > >> svint32_t v2 =3D svld1rq_s32 (svptrue_b8 (), &v[0]); > > > > > > > > > >> return v2; > > > > > > > > > >> } > > > > > > > > > >> > > > > > > > > > >> foo2.c: In function =E2=80=98foo=E2=80=99: > > > > > > > > > >> foo2.c:9:1: error: non-trivial conversion in =E2=80=98= vector_cst=E2=80=99 > > > > > > > > > >> 9 | } > > > > > > > > > >> | ^ > > > > > > > > > >> svint32_t > > > > > > > > > >> int32x4_t > > > > > > > > > >> v2_4 =3D { 1, 2, 3, 4 }; > > > > > > > > > >> > > > > > > > > > >> because simplify_permutation folds > > > > > > > > > >> VEC_PERM_EXPR< {1, 2, 3, 4}, {1, 2, 3, 4}, {0, 1, 2, 3= , ...} > > > > > > > > > > >> into: > > > > > > > > > >> vector_cst {1, 2, 3, 4} > > > > > > > > > >> > > > > > > > > > >> and it complains during verify_gimple_assign_single be= cause we don't > > > > > > > > > >> support assignment of vector_cst to VLA vector. > > > > > > > > > >> > > > > > > > > > >> I guess the issue really is that currently, only VEC_P= ERM_EXPR > > > > > > > > > >> supports lhs and rhs > > > > > > > > > >> to have vector types with differing lengths, and simpl= ifying it to > > > > > > > > > >> other tree codes, like above, > > > > > > > > > >> will result in type errors ? > > > > > > > > > > > > > > > > > > > > That might be the case - Richard should know. > > > > > > > > > > > > > > > > > > I don't see anything particularly special about VEC_PERM_= EXPR here, > > > > > > > > > or about the VLA vs. VLS thing. We would have the same i= ssue trying > > > > > > > > > to build a 128-bit vector from 2 64-bit vectors. And the= re are other > > > > > > > > > tree codes whose input types are/can be different from th= eir output > > > > > > > > > types. > > > > > > > > > > > > > > > > > > So it just seems like a normal type correctness issue: a = VEC_PERM_EXPR > > > > > > > > > of type T needs to be replaced by something of type T. W= hether T has a > > > > > > > > > constant size or a variable size doesn't matter. > > > > > > > > > > > > > > > > > > > If so your type check > > > > > > > > > > is still too late, you should instead recognize that we= are permuting > > > > > > > > > > a VLA vector and then refuse to go any of the non-VEC_P= ERM generating > > > > > > > > > > paths - that probably means just allowing the code =3D= =3D VEC_PERM_EXPR > > > > > > > > > > case and not any of the CTOR/CST/VIEW_CONVERT_EXPR case= s? > > > > > > > > > > > > > > > > > > Yeah. If we're talking about the match.pd code, I think = only: > > > > > > > > > > > > > > > > > > (if (sel.series_p (0, 1, 0, 1)) > > > > > > > > > { op0; } > > > > > > > > > (if (sel.series_p (0, 1, nelts, 1)) > > > > > > > > > { op1; } > > > > > > > > > > > > > > > > > > need a type compatibility check. For fold_vec_perm I thi= nk > > > > > > > > > we should just rearrange: > > > > > > > > > > > > > > > > > > gcc_assert (known_eq (TYPE_VECTOR_SUBPARTS (type), nelt= s) > > > > > > > > > && known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYP= E (arg0)), nelts) > > > > > > > > > && known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYP= E (arg1)), nelts)); > > > > > > > > > if (TREE_TYPE (TREE_TYPE (arg0)) !=3D TREE_TYPE (type) > > > > > > > > > || TREE_TYPE (TREE_TYPE (arg1)) !=3D TREE_TYPE (typ= e)) > > > > > > > > > return NULL_TREE; > > > > > > > > > > > > > > > > > > so that the assert comes after the early-out. > > > > > > > > > > > > > > > > > > It would be good at some point to relax fold_vec_perm to = cases where the > > > > > > > > > outputs are a different length from the inputs, since the= all-constant > > > > > > > > > VEC_PERM_EXPR above could be folded to a VECTOR_CST. > > > > > > > > Hi, > > > > > > > > For the above case, I think the issue is that simplify_perm= utation > > > > > > > > uses TREE_TYPE (arg0) for res_type, > > > > > > > > while it should now use type for lhs. > > > > > > > > > > > > > > > > /* Shuffle of a constructor. */ > > > > > > > > bool ret =3D false; > > > > > > > > tree res_type =3D TREE_TYPE (arg0); > > > > > > > > tree opt =3D fold_ternary (VEC_PERM_EXPR, res_type, a= rg0, arg1, op2); > > > > > > > > > > > > > > > > Using, res_type =3D TREE_TYPE (gimple_get_lhs (stmt)), > > > > > > > > resolves the ICE, and emits all constant VEC_PERM_EXPR: > > > > > > > > > > > > > > > > v2_4 =3D VEC_PERM_EXPR <{ 1, 2, 3, 4 }, { 1, 2, 3, 4 }, {= 0, 1, 2, 3, ... }>; > > > > > > > > return v2_4; > > > > > > > > > > > > > > > > Does the patch look OK to commit after bootstrap+test ? > > > > > > > > > > > > > > Ok with using gimple_assign_lhs (stmt) instead of gimple_get_= lhs (stmt). > > > > > > Hi, > > > > > > I committed the patch but unfortunately it caused PR106360. > > > > > > The issue is that for slp-reduc-sad-2.c on ppc64le, > > > > > > simplify_permutation sees the following during forwprop4: > > > > > > > > > > > > _78 =3D (void *) ivtmp.21_73; > > > > > > _92 =3D MEM [(uint8_t *)_78]; > > > > > > _91 =3D {_92, 0}; > > > > > > vect__1.6_90 =3D VIEW_CONVERT_EXPR(= _91); > > > > > > _88 =3D MEM [(uint8_t *)_78 + 16B]; > > > > > > _87 =3D {_88, 0}; > > > > > > vect__1.7_86 =3D VIEW_CONVERT_EXPR(= _87); > > > > > > vect__1.8_85 =3D VEC_PERM_EXPR > > > > > 3, 4, 5, 6, 7, 16, 17, 18, 19, 20, 21, 22, 23 }>; > > > > > > > > > > > > So for, > > > > > > tree res_type =3D TREE_TYPE (gimple_assign_lhs (stmt)); > > > > > > tree opt =3D fold_ternary (VEC_PERM_EXPR, res_type, arg0, arg1,= op2); > > > > > > > > > > > > we have: > > > > > > res_type =3D V16QI > > > > > > arg0 =3D {_92, 0} > > > > > > arg1 =3D {_88, 0} > > > > > > op2 =3D {0, 2} > > > > > > > > > > > > and thus we hit the following assert in fold_vec_perm: > > > > > > > > > > > > gcc_assert (known_eq (TYPE_VECTOR_SUBPARTS (type), nelts) > > > > > > && known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg= 0)), nelts) > > > > > > && known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg= 1)), nelts)); > > > > > > > > > > > > since nelts =3D=3D 2, and TYPE_VECTOR_SUBPARTS (type) =3D=3D 16= . > > > > > > > > > > > > If we revert the committed patch so we pass res_type =3D TREE_T= YPE (arg0) instead, > > > > > > it simplifies the above VEC_PERM_EXPR to VIEW_CONVERT_EXPR: > > > > > > _92 =3D MEM [(uint8_t *)_78]; > > > > > > _88 =3D MEM [(uint8_t *)_78 + 16B]; > > > > > > _5 =3D {_92, _88}; > > > > > > vect__1.8_85 =3D VIEW_CONVERT_EXPR(= _5); > > > > > > > > > > > > I suppose it's legal to cast vector of one type to another as l= ong as > > > > > > sizes match ? > > > > > > > > > > > > IIUC, the above VIEW_CONVERT_EXPR will result in: > > > > > > vect__1.8_85 =3D { (uint8_t) _92, 0, 0, 0, 0, 0, 0, 0, (uint8_t= ) _88, 0, > > > > > > 0, 0, 0, 0, 0, 0 } ? > > > > > > > > > > > > In the attached patch, it restores res_type to TREE_TYPE (arg0)= , and checks > > > > > > if lhs_type and res_type differ but have same size, and in that= case emit: > > > > > > lhs =3D VIEW_CONVERT_EXPR (opt), > > > > > > instead of: > > > > > > lhs =3D VIEW_CONVERT_EXPR (opt) > > > > > > where opt is result of folding VEC_PERM_EXPR > > > > > > > > > > > > Does it look OK ? > > > > > > > > > > Definitely the original change was bogus. > > > > > > > > > > + if (!operand_equal_p (TYPE_SIZE (lhs_type), TYPE_SIZE (= res_type))) > > > > > + return 0; > > > > > > > > > > just repeats your very original change though ... I'll note that > > > > > fold_ternary will > > > > > ICE on now valid VEC_PERM_EXPRs so we should fix it, possibly by > > > > > returning NULL_TREE on cases it does not handle. > > > > > > > > > > I think what should be done is, in the > > > > > > > > > > /* If there are any VIEW_CONVERT_EXPRs found when finding p= ermutation > > > > > operands source, check whether it's valid to transform a= nd prepare > > > > > the required new operands. */ > > > > > if (code =3D=3D VIEW_CONVERT_EXPR || code2 =3D=3D VIEW_CONV= ERT_EXPR) > > > > > { > > > > > ... > > > > > > > > > > path also transform the expected result type. It should remain V= _C_E compatible > > > > > to TREE_TYPE (lhs) but get a new element type. > > > > > > > > > > But as said, > > > > > > > > > > tree > > > > > fold_vec_perm (tree type, tree arg0, tree arg1, const vec_perm_in= dices &sel) > > > > > { > > > > > unsigned int i; > > > > > unsigned HOST_WIDE_INT nelts; > > > > > bool need_ctor =3D false; > > > > > > > > > > if (!sel.length ().is_constant (&nelts)) > > > > > return NULL_TREE; > > > > > gcc_assert (known_eq (TYPE_VECTOR_SUBPARTS (type), nelts) > > > > > && known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0)= ), nelts) > > > > > && known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg1)= ), nelts)); > > > > > > > > > > ^^^ this doesn't match what we allow for VEC_PERM_EXPRs now and f= old_ternary > > > > > doesn't guard according to those asserts (I think we should exten= d fold_vec_perm > > > > > to support the new constraints). > > > > Hi Richard, > > > > Thanks for the suggestions and sorry for late reply. I reverted the= change to > > > > simplify_permutaton which resolved the ppc64le case ICE. > > > > > > > > The attached patch extends fold_vec_perm to handle vectors with > > > > differing lengths. > > > > For, > > > > lhs =3D vec_perm_expr, > > > > the patch: > > > > (a) asserts lhs and mask have same vector length. > > > > (b) asserts arg0 and arg1 have same vector length. > > > > (c) returns NULL_TREE if element type differs for lhs, arg0 and arg= 1. > > > > (d) if len(lhs) > len(arg0), then the patch allows permuting arg0, = arg1 > > > > if the mask has npatterns =3D=3D len(arg0) and nelts_per_pattern = =3D=3D 1. > > > > The intent is to permute arg0 and arg1, and then to dup elements in= result > > > > to target vector length. > > > > So for eg: > > > > vec_perm_expr< {1, 2, 3, 4}, {5, 6, 7, 8}, {0, 4, 1, 5, ...}> > > > > will result in vla vector {1, 5, 2, 6, ....} with {1, 5, 2, 6} > > > > replicated thru-out. > > > > Does it look OK ? > > > > > > > > With the patch, we don't ICE for either of the aarch64 tests above. > > > > For, > > > > svint32_t f1() > > > > { > > > > int32x4_t v =3D {1, 2, 3, 4}; > > > > return svld1rq_s32 (svptrue_b8 (), &v[0]); > > > > } > > > > > > > > optimized dump shows: > > > > svint32_t f1 () > > > > { > > > > int32x4_t v; > > > > > > > > : > > > > return { 1, 2, 3, 4, ... }; > > > > > > > > } > > > > > > > > code-gen: > > > > f1: > > > > .LFB3900: > > > > .cfi_startproc > > > > ptrue p0.b, all > > > > adrp x0, .LC0 > > > > add x0, x0, :lo12:.LC0 > > > > ld1rqw z0.s, p0/z, [x0] > > > > ret > > > > .LC0: > > > > .word 1 > > > > .word 2 > > > > .word 3 > > > > .word 4 > > > > > > > > I guess for this particular case, we could use index instead. > > > > > > > > For, > > > > svint32_t f2(int a, int b, int c, int d) > > > > { > > > > int32x4_t v =3D {a, b, c, d}; > > > > return svld1rq_s32 (svptrue_b8 (), &v[0]); > > > > } > > > > > > > > optimized dump shows: > > > > svint32_t f2 (int a, int b, int c, int d) > > > > { > > > > svint32_t _6; > > > > > > > > [local count: 1073741824]: > > > > _6 =3D {a_1(D), b_2(D), c_3(D), d_4(D), ... }; > > > > return _6; > > > > > > > > The code-gen seems pretty bad however: > > > > f2: > > > > .LFB3901: > > > > .cfi_startproc > > > > addvl sp, sp, #-4 > > > > .cfi_escape 0xf,0x9,0x8f,0,0x92,0x2e,0,0x8,0x20,0x1e,0x22 > > > > ptrue p0.b, all > > > > addvl x4, sp, #3 > > > > mov z0.b, #0 > > > > st1w z0.s, p0, [sp, #3, mul vl] > > > > str w0, [x4] > > > > addvl x0, sp, #2 > > > > ld1w z0.s, p0/z, [sp, #3, mul vl] > > > > st1w z0.s, p0, [sp, #2, mul vl] > > > > str w1, [x0, 4] > > > > addvl x0, sp, #1 > > > > ld1w z0.s, p0/z, [sp, #2, mul vl] > > > > st1w z0.s, p0, [sp, #1, mul vl] > > > > str w2, [x0, 8] > > > > ld1w z0.s, p0/z, [sp, #1, mul vl] > > > > st1w z0.s, p0, [sp] > > > > str w3, [sp, 12] > > > > ld1w z0.s, p0/z, [sp] > > > > addvl sp, sp, #4 > > > > .cfi_def_cfa_offset 0 > > > > ret > > > > > > > > I will try to address code-gen issues in follow up patches. > > > > Bootstrapped+tested on x64_64-linux-gnu and aarch64-linux-gnu. > > > > > > > > > /* If result vector has greater length than input vector, > > > + then allow permuting two vectors as long as: > > > + a) sel.nelts_per_pattern =3D=3D 1 > > > + b) sel.npatterns =3D=3D len of input vector. > > > + The intent is to permute input vectors, and > > > + dup the elements in resulting vector to target vector length. = */ > > > + > > > + if (maybe_gt (TYPE_VECTOR_SUBPARTS (type), > > > + TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0)))) > > > + { > > > + nelts =3D sel.encoding ().npatterns (); > > > + if (sel.encoding ().nelts_per_pattern () !=3D 1 > > > + || (!known_eq (nelts, TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0= ))))) > > > + return NULL_TREE; > > > + } > > > > > > so the only case you add is non-VLA to VLA and there > > > explicitely only the case of a period that's same as the > > > element count in the input vectors. > > > > > > > > > @@ -2602,6 +2602,9 @@ dump_generic_node (pretty_printer *pp, tree > > > node, int spc, dump_flags_t flags, > > > pp_space (pp); > > > } > > > } > > > + if (VECTOR_TYPE_P (TREE_TYPE (node)) > > > + && !TYPE_VECTOR_SUBPARTS (TREE_TYPE (node)).is_constant (= )) > > > + pp_string (pp, ", ... "); > > > pp_right_brace (pp); > > > > > > btw, I do wonder if VLA CONSTRUCTORs are a "thing"? Are they? > > Well, it got created for the following case after folding: > > svint32_t f2(int a, int b, int c, int d) > > { > > int32x4_t v =3D {a, b, c, d}; > > return svld1rq_s32 (svptrue_b8 (), &v[0]); > > } > > > > The svld1rq_s32 call gets folded to: > > v =3D {a, b, c, d} > > lhs =3D VEC_PERM_EXPR > > > > fold_vec_perm then folds the above VEC_PERM_EXPR to > > VLA constructor, since elements in v (in_elts) are not constant, and > > need_ctor is thus true: > > lhs =3D {a, b, c, d, ...} > > I added "..." to make it more explicit that it's a VLA constructor. > > But I doubt we do anything reasonable with such a beast? Do we? > I suppose it's like a vec_duplicate if you view it as V1TImode > but do we actually make sure to do this duplication? I am not sure. As mentioned above, the current code-gen for VLA constructor looks pretty bad. Should we avoid folding VLA constructors for now ? I guess these are 2 different issues: (a) Resolving ICE with VEC_PERM_EXPR for above aarch64 tests. (b) Extending fold_vec_perm to handle vectors with differing lengths. For (a), I think the issue with using: res_type =3D gimple_assign_lhs (stmt) in previous patch, was that op2's type will change to match tgt_units, if we go thru (code =3D=3D VIEW_CONVERT_EXPR || code2 =3D=3D VIEW_CONVERT_EXPR) branch, and may thus not be same as len(lhs_type) anymore, and hit the assert in fold_vec_perm. IIUC, for lhs =3D VEC_PERM_EXPR, we now have the following semantics: (1) Element types for lhs, rhs1 and rhs2 should be the same. (2) len(lhs) =3D=3D len(mask) and len(rhs1) =3D=3D len(rhs2). The attached patch changes res_type from TREE_TYPE (arg0) to following: res_type =3D build_vector_type (TREE_TYPE (TREE_TYPE (arg0)), TYPE_VECTOR_SUBPARTS (op2)) so it has same element type as arg0 (and arg1) and len of op2. Does that look reasonable ? If we need a cast from res_type to lhs_type, then both would be fixed width vectors with len(lhs_type) being a multiple of len(res_type). IIUC, we don't support casting from VLA vector to/from fixed width vector, or from VLA vector of one type to VLA vector of other type ? Currently, if op2 is VLA, and we enter the branch: (code =3D=3D VIEW_CONVERT_EXPR || code2 =3D=3D VIEW_CONVERT_EXPR) then I think it will bail out because op2_units will not be a compile time constant, and constant_multiple_p (op2_units, tgt_units, &factor) would return false. The patch resolves ICE's for aarch64 cases, without regressing the ones in PR106360. Does it look OK ? I have a WIP patch for extending fold_vec_perm to fold VLA vectors, that I will post shortly. Thanks, Prathamesh > > > > > > > I had hoped that you would make > > > > > > tree *in_elts =3D XALLOCAVEC (tree, nelts * 2); > > > if (!vec_cst_ctor_to_array (arg0, nelts, in_elts) > > > || !vec_cst_ctor_to_array (arg1, nelts, in_elts + nelts)) > > > return NULL_TREE; > > > > > > VLA agnostic, thus support for example permuting > > > { 0, 2, 4, 8, ... }, { 1, 3, 5, 7 ... }, { 0, 4, 1, 5 ... } > > > as { 0, 1, 2, 3, ... }, etc. > > > > > > that should be entirely doable, to somebody familiar with VLA and the= APIs > > > even more so. > > Thanks, I will work on adding this case. > > > > Thanks, > > Prathamesh > > > > > > Richard. > > > > > > > Thanks, > > > > Prathamesh > > > > > > > > > > > > > > Richard. > > > > > > > > > > > Thanks, > > > > > > Prathamesh > > > > > > > > > > > > > > > > > > > > > I will try to address the folding for above VEC_PERM_EXPR i= n follow-up patch. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Prathamesh > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Richard --0000000000005a0fc605e5f71397 Content-Type: text/plain; charset="US-ASCII"; name="gnu-790-4.txt" Content-Disposition: attachment; filename="gnu-790-4.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l6p2h08e0 ZGlmZiAtLWdpdCBhL2djYy9mb2xkLWNvbnN0LmNjIGIvZ2NjL2ZvbGQtY29uc3QuY2MKaW5kZXgg OTkwMjFhODJkZjQuLmJjOGJhNDYwN2E1IDEwMDY0NAotLS0gYS9nY2MvZm9sZC1jb25zdC5jYwor KysgYi9nY2MvZm9sZC1jb25zdC5jYwpAQCAtMTA1NDEsMTUgKzEwNTQxLDI0IEBAIGZvbGRfdmVj X3Blcm0gKHRyZWUgdHlwZSwgdHJlZSBhcmcwLCB0cmVlIGFyZzEsIGNvbnN0IHZlY19wZXJtX2lu ZGljZXMgJnNlbCkKICAgdW5zaWduZWQgSE9TVF9XSURFX0lOVCBuZWx0czsKICAgYm9vbCBuZWVk X2N0b3IgPSBmYWxzZTsKIAotICBpZiAoIXNlbC5sZW5ndGggKCkuaXNfY29uc3RhbnQgKCZuZWx0 cykpCi0gICAgcmV0dXJuIE5VTExfVFJFRTsKLSAgZ2NjX2Fzc2VydCAoa25vd25fZXEgKFRZUEVf VkVDVE9SX1NVQlBBUlRTICh0eXBlKSwgbmVsdHMpCi0JICAgICAgJiYga25vd25fZXEgKFRZUEVf VkVDVE9SX1NVQlBBUlRTIChUUkVFX1RZUEUgKGFyZzApKSwgbmVsdHMpCi0JICAgICAgJiYga25v d25fZXEgKFRZUEVfVkVDVE9SX1NVQlBBUlRTIChUUkVFX1RZUEUgKGFyZzEpKSwgbmVsdHMpKTsK KyAgZ2NjX2Fzc2VydCAoa25vd25fZXEgKFRZUEVfVkVDVE9SX1NVQlBBUlRTICh0eXBlKSwKKwkJ CXNlbC5sZW5ndGggKCkpKTsKKyAgZ2NjX2Fzc2VydCAoa25vd25fZXEgKFRZUEVfVkVDVE9SX1NV QlBBUlRTIChUUkVFX1RZUEUgKGFyZzApKSwKKwkJCVRZUEVfVkVDVE9SX1NVQlBBUlRTIChUUkVF X1RZUEUgKGFyZzEpKSkpOworCiAgIGlmIChUUkVFX1RZUEUgKFRSRUVfVFlQRSAoYXJnMCkpICE9 IFRSRUVfVFlQRSAodHlwZSkKICAgICAgIHx8IFRSRUVfVFlQRSAoVFJFRV9UWVBFIChhcmcxKSkg IT0gVFJFRV9UWVBFICh0eXBlKSkKICAgICByZXR1cm4gTlVMTF9UUkVFOwogCisgIC8qIFRPRE86 IEhhbmRsZSBWRUNfUEVSTV9FWFBSIHdpdGggZGlmZmVyaW5nIGxlbmd0aHMuICAqLworICBpZiAo IWtub3duX2VxIChUWVBFX1ZFQ1RPUl9TVUJQQVJUUyAodHlwZSksCisJCSBUWVBFX1ZFQ1RPUl9T VUJQQVJUUyAoVFJFRV9UWVBFIChhcmcwKSkpKQorICAgIHJldHVybiBOVUxMX1RSRUU7CisKKyAg LyogVE9ETzogSGFuZGxlIFZMQSB2ZWN0b3JzLiAgKi8KKyAgaWYgKCFzZWwubGVuZ3RoICgpLmlz X2NvbnN0YW50ICgmbmVsdHMpKQorICAgIHJldHVybiBOVUxMX1RSRUU7CisKICAgdHJlZSAqaW5f ZWx0cyA9IFhBTExPQ0FWRUMgKHRyZWUsIG5lbHRzICogMik7CiAgIGlmICghdmVjX2NzdF9jdG9y X3RvX2FycmF5IChhcmcwLCBuZWx0cywgaW5fZWx0cykKICAgICAgIHx8ICF2ZWNfY3N0X2N0b3Jf dG9fYXJyYXkgKGFyZzEsIG5lbHRzLCBpbl9lbHRzICsgbmVsdHMpKQpkaWZmIC0tZ2l0IGEvZ2Nj L21hdGNoLnBkIGIvZ2NjL21hdGNoLnBkCmluZGV4IDMzMGMxZGIwYzhlLi5hYTIwY2M3MTNjNSAx MDA2NDQKLS0tIGEvZ2NjL21hdGNoLnBkCisrKyBiL2djYy9tYXRjaC5wZApAQCAtNzg0NSw2ICs3 ODQ1LDEyIEBAIGFuZCwKICAod2l0aAogICB7CiAgICAgdHJlZSBvcDAgPSBAMCwgb3AxID0gQDEs IG9wMiA9IEAyOworCisgICAgZ2NjX2Fzc2VydCAoa25vd25fZXEgKFRZUEVfVkVDVE9SX1NVQlBB UlRTICh0eXBlKSwKKwkJCSAgVFlQRV9WRUNUT1JfU1VCUEFSVFMgKFRSRUVfVFlQRSAob3AyKSkp KTsKKyAgICBnY2NfYXNzZXJ0IChrbm93bl9lcSAoVFlQRV9WRUNUT1JfU1VCUEFSVFMgKFRSRUVf VFlQRSAob3AwKSksCisJCQkgIFRZUEVfVkVDVE9SX1NVQlBBUlRTIChUUkVFX1RZUEUgKG9wMSkp KSk7CisKICAgICBtYWNoaW5lX21vZGUgcmVzdWx0X21vZGUgPSBUWVBFX01PREUgKHR5cGUpOwog ICAgIG1hY2hpbmVfbW9kZSBvcF9tb2RlID0gVFlQRV9NT0RFIChUUkVFX1RZUEUgKG9wMCkpOwog CmRpZmYgLS1naXQgYS9nY2MvdHJlZS1zc2EtZm9yd3Byb3AuY2MgYi9nY2MvdHJlZS1zc2EtZm9y d3Byb3AuY2MKaW5kZXggZmRjNGJjODkwOWQuLjRiNjkzZWYwOTVjIDEwMDY0NAotLS0gYS9nY2Mv dHJlZS1zc2EtZm9yd3Byb3AuY2MKKysrIGIvZ2NjL3RyZWUtc3NhLWZvcndwcm9wLmNjCkBAIC0y NjYxLDcgKzI2NjEsOSBAQCBzaW1wbGlmeV9wZXJtdXRhdGlvbiAoZ2ltcGxlX3N0bXRfaXRlcmF0 b3IgKmdzaSkKIAogICAgICAgLyogU2h1ZmZsZSBvZiBhIGNvbnN0cnVjdG9yLiAgKi8KICAgICAg IGJvb2wgcmV0ID0gZmFsc2U7Ci0gICAgICB0cmVlIHJlc190eXBlID0gVFJFRV9UWVBFIChhcmcw KTsKKyAgICAgIHRyZWUgcmVzX3R5cGUKKwk9IGJ1aWxkX3ZlY3Rvcl90eXBlIChUUkVFX1RZUEUg KFRSRUVfVFlQRSAoYXJnMCkpLAorCQkJICAgICBUWVBFX1ZFQ1RPUl9TVUJQQVJUUyAoVFJFRV9U WVBFIChvcDIpKSk7CiAgICAgICB0cmVlIG9wdCA9IGZvbGRfdGVybmFyeSAoVkVDX1BFUk1fRVhQ UiwgcmVzX3R5cGUsIGFyZzAsIGFyZzEsIG9wMik7CiAgICAgICBpZiAoIW9wdAogCSAgfHwgKFRS RUVfQ09ERSAob3B0KSAhPSBDT05TVFJVQ1RPUiAmJiBUUkVFX0NPREUgKG9wdCkgIT0gVkVDVE9S X0NTVCkpCg== --0000000000005a0fc605e5f71397--