gimple-fold: Fix handling of vdefs for MASK_LOAD_LANES replacement [PR123776]

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.

	PR tree-optimization/123776

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 <andrew.pinski@oss.qualcomm.com>

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;
 	}