From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id D86C838582BE for ; Thu, 14 Jul 2022 08:34:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D86C838582BE Received: by mail-ej1-x630.google.com with SMTP id va17so2188666ejb.0 for ; Thu, 14 Jul 2022 01:34:05 -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:cc:content-transfer-encoding; bh=ENb6Ewj00O5PzG7dUHh6FxPDfD7fNP9jrU2WuBJ0rJA=; b=C8cD0glVFa55/vqBME3OOnyxvtHay2x83bNw+fb/tBNQWCypGhrK+hbU/r3l2WEhzY jjTWk6VyOaEnpqP9UIU9uobPVU96FKhvjkBaBkKxZo/m5MSfwgEz5UDpNfqyStZUY5b6 pTX29QWomCQnFv7ao8jvx/45Hiz7EHFTyjmp1eq7Wbw/vwIiEu3EzIjQarG2tlNPV7FS /DVqcWL4lBA6opSweLWOfOtb++sew7V49s6qN/vpf86IHrt42QRQBS7BG+sUYZoEHRTo tuASOLNw+BIu4gViKfZuouhk2a6mpNUMM7VSRq/tEAnhkmd/EGRNWcQtU1NK7z7lNjxE ZhyQ== X-Gm-Message-State: AJIora89G+AE6GMToUJU9oSr6x3ebmgkD+uW5yaL0f+b31UgfOfBrGUe vQ2eY80dE37jVet2i2ew6Za0JQJRwOjEMAEtlZI= X-Google-Smtp-Source: AGRyM1vfmeZ0NN653qyTJD5FK6FGH8MrsFt3pDacOsRqNuqxGJ6e4JbN4gu0nX/66CWdXFGH5Ue1G2PHSZuQQfnwESs= X-Received: by 2002:a17:907:3f1d:b0:726:c927:769b with SMTP id hq29-20020a1709073f1d00b00726c927769bmr7691574ejc.754.1657787644557; Thu, 14 Jul 2022 01:34:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 14 Jul 2022 10:33:52 +0200 Message-ID: Subject: Re: ICE after folding svld1rq to vec_perm_expr duing forwprop To: Prathamesh Kulkarni Cc: gcc Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 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, 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, 14 Jul 2022 08:34:08 -0000 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=3Dgeneric+sve: > > > foo.c: In function =E2=80=98f2=E2=80=99: > > > foo.c:4:11: error: non-trivial conversion in =E2=80=98view_convert_ex= pr=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 vec_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 VIEW_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 compatible types, > > > which resolves ICE, but am not sure if it's the correct approach ? > > > > It for sure papers over the issue. I think the error happens earlier, > > the V_C_E should have been built with the type of the 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_PERM_EXPR to > represent dup operation > from fixed width to VLA vector. I am not sure how folding 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=98vector_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 because we don't > support assignment of vector_cst to VLA vector. > > I guess the issue really is that currently, only VEC_PERM_EXPR > supports lhs and rhs > to have vector types with differing lengths, and simplifying it to > other tree codes, like above, > will result in type errors ? That might be the case - Richard should know. 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_PERM 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 cases? Richard. > > Thanks, > Prathamesh > > > > > > > > Alternatively, should we allow assignments from fixed-width to SVE > > > vector, so the above > > > VIEW_CONVERT_EXPR would result in dup ? > > > > > > Thanks, > > > Prathamesh