When determining the replacement access during cloning, we currently
leave accesses for instructions that are not in the VMap alone. This is
correct if the instruction is not in VMap because it hasn't been cloned,
but not if it has been cloned and then removed. In that case, we should
walk up to the defining access, like in other simplification cases.

To distinguish the two cases, pass in a callback that queries whether
the instruction is part of the cloned region.

An alternative to this would be to delay removal of dead instructions in
SimpleLoopUnswitch until after MSSA cloning.

Fixes https://github.com/llvm/llvm-project/issues/116228.

Fixes #116809.

After running some passes (SimpleLoopUnswitch, LoopInstSimplify, etc.),
MemorySSA might be outdated, and the instruction `I` may have become a
non-memory touching instruction.

LICM has already handled this, but it does not pass
`CreationMustSucceed=false` to `createDefinedAccess`.

This is a followup to #76819. After those changes, we can still run into
an assertion failure for a slight variation of the test case: When
fixing up MemoryPhis, we map the incoming access to the access of the
cloned instruction -- which may now no longer exist.

Fix this by reusing the getNewDefiningAccessForClone() helper, which
will look upwards for a new defining access in that case.

Sometimes, we create a MemoryAccess for an instruction, which is later
simplified (e.g. via devirtualization) such that the new instruction has
no memory effects anymore.

If we later clone the instruction (e.g. during unswitching), then MSSA
will not create a MemoryAccess for the new instruction, triggering an
assert.

Disable the assertion (by passing CreationMustSucceed=false) and adjust
getDefiningAccessForClone() to work correctly in that case.

This PR implements the alternative suggestion by alinas from
https://github.com/llvm/llvm-project/pull/76142.

Fix for https://github.com/llvm/llvm-project/issues/51257.

Differential Revision: https://reviews.llvm.org/D122601

Number of lines output by preprocessor:
before: 1065940348
after:  1065307662

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D120659

The problem can be shown from the newly added test case.
There are two invocations to MemorySSAUpdater::moveToPlace, and the
internal data structure VisitedBlocks is changed in the first
invocation, and reused in the second invocation. In between the two
invocations, there is a change to the CFG, and MemorySSAUpdater is
notified about the change.

Reviewed By: asbirlea

Differential Revision: https://reviews.llvm.org/D119898