https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92803
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Untested fix:
--- gcc/tree-ssa-forwprop.c.jj 2019-12-03 20:21:30.554464396 +0100
+++ gcc/tree-ssa-forwprop.c 2019-12-04 17:48:36.351450274 +0100
@@ -2283,11 +2283,11 @@ simplify_vector_constructor (gimple_stmt
gimple_seq stmts = NULL;
if (!orig[1])
orig[1] = orig[0];
- else if (orig[1] == error_mark_node
- && one_nonconstant)
+ else if (orig[1] == error_mark_node && one_nonconstant)
{
orig[1] = gimple_build_vector_from_val (&stmts, UNKNOWN_LOCATION,
- type, one_nonconstant);
+ TREE_TYPE (orig[0]),
+ one_nonconstant);
/* ??? We can see if we can safely convert to the original
element type. */
converted_orig1 = conv_code != ERROR_MARK;
Though, there is another issue, for the nelts 2 vectors
simplify_vector_constructor created code is actually larger than old code.
And, it might be beneficial if we one day implement clang-like
__builtin_shufflevector or at least add to VEC_PERM_EXPR or something similar
the possibility to say certain element is a don't care (for
__builtin_shufflevector I think that is -1 or negative?), as e.g. on AVX/AVX2
when extracting 128-bit vector out of 256-bit permutation all the upper
elements are don't care and we might get better code if the backend picks the
best element indexes for those to get smallest/fastest permutation.
