@@ -3504,14 +3504,19 @@ vectorizable_operation (gimple stmt, gim
{
decl1 = NULL_TREE;
decl2 = NULL_TREE;
- optab = optab_for_tree_code (VEC_WIDEN_MULT_HI_EXPR,
+ optab = optab_for_tree_code (VEC_WIDEN_MULT_LO_EXPR,
vectype, optab_default);
optab2 = optab_for_tree_code (VEC_WIDEN_MULT_HI_EXPR,
vectype, optab_default);
if (optab != NULL
&& optab2 != NULL
&& optab_handler (optab, vec_mode) != CODE_FOR_nothing
- && optab_handler (optab2, vec_mode) != CODE_FOR_nothing)
+ && optab_handler (optab2, vec_mode) != CODE_FOR_nothing
+ && insn_data[optab_handler (optab, vec_mode)].operand[0].mode
+ == TYPE_MODE (wide_vectype)
+ && insn_data[optab_handler (optab2,
+ vec_mode)].operand[0].mode
+ == TYPE_MODE (wide_vectype))
{
for (i = 0; i < nunits_in; i++)
sel[i] = !BYTES_BIG_ENDIAN + 2 * i;
On Fri, Jun 29, 2012 at 12:00:10AM +0200, Bernhard Reutner-Fischer wrote: > Really both HI? If so optab2 could be removed from that fn altogether.. Of course, thanks for pointing that out. I've additionally added a result mode check (similar to what supportable_widening_operation does). The reason for not using supportable_widening_operation is that it only tests even/odd calls for reductions, while we can use them everywhere. Committed as obvious. 2012-06-29 Jakub Jelinek <jakub@redhat.com> * tree-vect-stmts.c (vectorizable_operation): Check both VEC_WIDEN_MULT_LO_EXPR and VEC_WIDEN_MULT_HI_EXPR optabs. Verify that operand[0]'s mode is TYPE_MODE (wide_vectype). Jakub