From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) by sourceware.org (Postfix) with ESMTPS id 377F23858434 for ; Wed, 13 Jul 2022 06:52:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 377F23858434 Received: by mail-qv1-xf32.google.com with SMTP id l2so4216078qvt.2 for ; Tue, 12 Jul 2022 23:52:04 -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=/VWs1rE2i1aJCMg8ngg5hwjYwvOe7/mFMUam1h5uDHg=; b=e6or2MvGuJcjwnyguvPa7QUoal9V8ZgBIQZ5lSE87V8O5TMJvVmhaklR5eSPwfJ1kn 884ttco5zmC4sEep6c3gwpgbr7qImLIHB56q0xLi/d3vl+p9mUB+Q4Gi3gAR91gkUvpG 4y54s0HwHVIrFvpa163CiMCgQda24J7vUk2oPCMTNUiqT9DHRH0FTlFJsQXW1zW07x+0 gZ70uTijloCjbXLcNX31ZA6XgEoTYOdhF0m6orQ3l+o8TWv6f0pVQB+vXLCC8F7l8qcu iNa5GrPkS5t1hRaKrHO56N5NhgxGoTNj2oTxdRgS7NgMwm+oWdGXBhN2nWEp5rF+5Qdi axTQ== X-Gm-Message-State: AJIora/CvsBl2z9uRwTbXw7D9Tj441TJ2qHQpnI8iP+ArR6Uwvzy7wR7 rXTjRQMW8/92U0qWKk8WEO1XZ0+uuknSn9lumxU= X-Google-Smtp-Source: AGRyM1vBqqjpFVuw3EnBdFF+eiGckgXP7ECpHLJaH00+wOwOr6/49Erj9TWcgcBmvPhwENKW2R8cJ5YtBCoDYpNGYxM= X-Received: by 2002:a05:6214:260b:b0:473:6ef4:491b with SMTP id gu11-20020a056214260b00b004736ef4491bmr1580462qvb.34.1657695123545; Tue, 12 Jul 2022 23:52:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Wed, 13 Jul 2022 08:51: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=-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, 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: Wed, 13 Jul 2022 06:52:05 -0000 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_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 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. > > Alternatively, should we allow assignments from fixed-width to SVE > vector, so the above > VIEW_CONVERT_EXPR would result in dup ? > > Thanks, > Prathamesh