vectorizable_call stubs out the original scalar statement with
a dummy assignment to the same lhs, so that we don't leave any bogus
scalar calls around. If the call is actually a pattern statement,
the code rightly took the lhs of the original bb statement:
if (is_pattern_stmt_p (stmt_info))
lhs = gimple_call_lhs (STMT_VINFO_RELATED_STMT (stmt_info));
else
lhs = gimple_call_lhs (stmt);
But it then associated the new statement with the stmt_vec_info of the
pattern statement rather than the bb statement, which meant we had two
stmt_vec_infos assigning to the same lhs. This seems to be latent at
the moment but caused problems further into the series.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Richard
2018-06-18 Richard Sandiford <richard.sandif...@arm.com>
gcc/
* tree-vect-stmts.c (vectorizable_call): Make sure that we
use the stmt_vec_info of the original bb statement for the
new zero assignment, even if the call is part of a pattern.
Index: gcc/tree-vect-stmts.c
===================================================================
--- gcc/tree-vect-stmts.c 2018-06-18 15:24:21.005379580 +0100
+++ gcc/tree-vect-stmts.c 2018-06-18 15:24:35.165254737 +0100
@@ -3611,13 +3611,12 @@ vectorizable_call (gimple *gs, gimple_st
type = TREE_TYPE (scalar_dest);
if (is_pattern_stmt_p (stmt_info))
- lhs = gimple_call_lhs (STMT_VINFO_RELATED_STMT (stmt_info));
- else
- lhs = gimple_call_lhs (stmt);
+ stmt_info = vinfo_for_stmt (STMT_VINFO_RELATED_STMT (stmt_info));
+ lhs = gimple_get_lhs (stmt_info->stmt);
new_stmt = gimple_build_assign (lhs, build_zero_cst (type));
set_vinfo_for_stmt (new_stmt, stmt_info);
- set_vinfo_for_stmt (stmt, NULL);
+ set_vinfo_for_stmt (stmt_info->stmt, NULL);
STMT_VINFO_STMT (stmt_info) = new_stmt;
gsi_replace (gsi, new_stmt, false);
