[Bug tree-optimization/69207] [6 Regression] gcc.target/aarch64/vldN_1.c ICEs at -O3

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69207

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems there is a mismatch in between fold_convertible_p and
verify_gimple_assign_unary (and also the gimplifier).
E.g. for this special case fold_convertible_p has some weird exception:
2188          return (TREE_CODE (orig) == VECTOR_TYPE
2189                  && tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE
(orig)));
But verify_gimple_assign_unary certainly doesn't allow that.  It has also
various other restrictions, e.g. on pointer conversions etc.
So, Richard, do we or should we have another predicate that says for outer and
inner type if it is ok to use GIMPLE_ASSIGN with NOP_EXPR?
Most of the uses that use fold_convertible_p in the middle-end actually perform
fold_convert or fold_build1 (... NOP_EXPR, ...), which creates a NOP_EXPR from
the VECTOR_TYPE to same sized integral type.  Strangely, when trying to
gimplify that it just creates a NOP_EXPR GIMPLE_ASSIGN, which then fails
verification.
So, what is the above mentioned 2188/2189 there for and corresponding
fold_convert_loc:
2246          gcc_assert (TREE_CODE (orig) == VECTOR_TYPE
2247                      && tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE
(orig)));
2248          return fold_build1_loc (loc, NOP_EXPR, type, arg);
Shall it not create a VCE instead?
Or shall it at least not gimplify to a VCE instead of a NOP_EXPR?
For the tree-vect-slp.c case it is of course enough to just replace
fold_convertible_p with INTEGRAL_TYPE_P && INTEGRAL_TYPE_P check, but I really
think we should figure out what we want and have proper predicates for it.