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

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> 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.

But that's invalid.  fold_convert does

    case VECTOR_TYPE:
      if (integer_zerop (arg))
        return build_zero_vector (type);
      gcc_assert (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig)));
      gcc_assert (INTEGRAL_TYPE_P (orig) || POINTER_TYPE_P (orig)
                  || TREE_CODE (orig) == VECTOR_TYPE);
      return fold_build1_loc (loc, VIEW_CONVERT_EXPR, type, arg);

thus always creates a VCE.

Note that fold_build1 (... NOP_EXPR ...) is _not_ equivalent to
fold_convert (...)!

>  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.

I think on gimple we can't simply use fold_convertible_p because that has
special handling for a lot of cases where it doesn't end up generating
a NOP_EXPR.  That is, if fold_convertible_p you can call fold_convert
without ICEing, you can't just build a NOP_EXPR gimple assign.