This was found when I was running the gcc testsuite with some SVE options to
enable SVE only vectorization and enable it always.
After r16-5984-gcee0a9dd2700b9 and r16-6918-g46a3355c7f1656, we would fold:
# .MEM_696 = VDEF <.MEM_695>
vect_array.781 = .MASK_LOAD_LANES (vectp_this.772_515, 64B, loop_mask_511, {
0, 0 });
into:
vect_array.781 = {};
But since this was originally a "load" we don't copy the vdef. Some passes
like fre will not cause a TODO_update_ssa to happen so we hit an assert
which basically says the we should have done an update_ssa.
While we could do an update_ssa, the better fix is to copy the vdef from
the old statement to the new one before doing the gsi_replace. When we
know this will be a store (in the !is_gimple_reg case). And then we have
kept the vop up to date and don't need to do an update_ssa.
Pushed as obvious after a build and test on aarch64-linux-gnu.
gcc/ChangeLog:
* gimple-fold.cc (gimple_fold_partial_load_store): Copy
the vdef from the old statement to the new statement of a
load that is also a store to non gimple_reg.
Signed-off-by: Andrew Pinski <[email protected]>
---
gcc/gimple-fold.cc | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
index 4766187e0b9..ec6831a20a0 100644
--- a/gcc/gimple-fold.cc
+++ b/gcc/gimple-fold.cc
@@ -5907,6 +5907,10 @@ gimple_fold_partial_load_store (gimple_stmt_iterator
*gsi, gcall *call)
}
gassign *new_stmt = gimple_build_assign (lhs, else_value);
gimple_set_location (new_stmt, gimple_location (call));
+ /* When the lhs is an array for LANES version, then there is still
+ a store, move the vops from the old stmt to the new one. */
+ if (!is_gimple_reg (lhs))
+ gimple_move_vops (new_stmt, call);
gsi_replace (gsi, new_stmt, false);
return true;
}
--
2.43.0
