On Wed, 13 Jul 2022 at 12:22, Richard Biener <richard.guent...@gmail.com> wrote: > > On Tue, Jul 12, 2022 at 9:12 PM Prathamesh Kulkarni via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > > > Hi Richard, > > For the following test: > > > > svint32_t f2(int a, int b, int c, int d) > > { > > int32x4_t v = (int32x4_t) {a, b, c, d}; > > return svld1rq_s32 (svptrue_b8 (), &v[0]); > > } > > > > The compiler emits following ICE with -O3 -mcpu=generic+sve: > > foo.c: In function ‘f2’: > > foo.c:4:11: error: non-trivial conversion in ‘view_convert_expr’ > > 4 | svint32_t f2(int a, int b, int c, int d) > > | ^~ > > svint32_t > > __Int32x4_t > > _7 = 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; > > > > <bb 2> : > > _1 = {a_3(D), b_4(D), c_5(D), d_6(D)}; > > v_12 = _1; > > _11 = v_12; > > _9 = 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 = {a_2(D), b_3(D), c_4(D), d_5(D)}; > > _7 = 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 = (int32x4_t) {1, 2, 3, 4}; svint32_t v2 = svld1rq_s32 (svptrue_b8 (), &v[0]); return v2; } foo2.c: In function ‘foo’: foo2.c:9:1: error: non-trivial conversion in ‘vector_cst’ 9 | } | ^ svint32_t int32x4_t v2_4 = { 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 ? 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