[3/n] PR85694: Fix dummy assignment handling in vectorizable_call
commitd1055d7bd74eb3eeb0b8ca1d658d13197034860f
authorrsandifo <rsandifo@138bc75d-0d04-0410-961f-82ee72b054a4>
Wed, 20 Jun 2018 08:06:33 +0000 (20 08:06 +0000)
committerrsandifo <rsandifo@138bc75d-0d04-0410-961f-82ee72b054a4>
Wed, 20 Jun 2018 08:06:33 +0000 (20 08:06 +0000)
treef0439f36d8ce7061d229946bd7478130edc6aaee
parentda6113101ab0698458303bc22a78be0133a53099
[3/n] PR85694: Fix dummy assignment handling in vectorizable_call

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.

2018-06-20  Richard Sandiford  <richard.sandiford@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.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@261786 138bc75d-0d04-0410-961f-82ee72b054a4
gcc/ChangeLog
gcc/tree-vect-stmts.c