aboutsummaryrefslogtreecommitdiff
path: root/gcc/tree-vect-patterns.c
diff options
context:
space:
mode:
authorRichard Sandiford <richard.sandiford@arm.com>2018-06-20 08:06:33 +0000
committerRichard Sandiford <rsandifo@gcc.gnu.org>2018-06-20 08:06:33 +0000
commited7b8123fab1de4d6da98774262c123f6d1226f9 (patch)
treef0439f36d8ce7061d229946bd7478130edc6aaee /gcc/tree-vect-patterns.c
parente3947d809d75c6bc47e600ce490c238006c2de2b (diff)
downloadgcc-ed7b8123fab1de4d6da98774262c123f6d1226f9.zip
gcc-ed7b8123fab1de4d6da98774262c123f6d1226f9.tar.gz
gcc-ed7b8123fab1de4d6da98774262c123f6d1226f9.tar.bz2
[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. From-SVN: r261786
Diffstat (limited to 'gcc/tree-vect-patterns.c')
0 files changed, 0 insertions, 0 deletions