http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Cong Hou from comment #4)
> Yes, there is a quick fix: we can check if the def with
> vect_used_by_reduction is immediately used by a reduction stmt. After all,
> it seems that supportable_widening_operation() is the only place that takes
> advantage of this "the element order doesn't matter" feature.
>
>
> diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> index 70fb411..7442d0c 100644
> --- a/gcc/tree-vect-stmts.c
> +++ b/gcc/tree-vect-stmts.c
> @@ -7827,7 +7827,16 @@ supportable_widening_operation (enum tree_code code,
> gimple stmt,
> stmt, vectype_out, vectype_in,
> code1, code2, multi_step_cvt,
> interm_types))
> - return true;
> + {
> + tree lhs = gimple_assign_lhs (stmt);
> + use_operand_p dummy;
> + gimple use_stmt;
> + stmt_vec_info use_stmt_info = NULL;
> + if (single_imm_use (lhs, &dummy, &use_stmt)
> + && (use_stmt_info = vinfo_for_stmt (use_stmt))
> + && STMT_VINFO_DEF_TYPE (use_stmt_info) == vect_reduction_def)
> + return true;
> + }
> c1 = VEC_WIDEN_MULT_LO_EXPR;
> c2 = VEC_WIDEN_MULT_HI_EXPR;
> break;
Looks good to me, perhaps just no need to initialize use_stmt_info to NULL.
Are you going to bootstrap/regtest this and post to gcc-patches?
