The general flow when inserting MemoryDefs is: * Insert the def and set it's defining access (may insert phis) * Insert IDF phis * Update defining access for defs after the new one (fixupDefs) * Rename uses if requested fixupDefs() uses getPreviousDef() which can create new MemoryPHIs, but for which we're not going to insert IDF phis, so the required dominance property may not hold. I believe this is a leftover from a time before the "Insert IDF phis" step existed. Now that step should already ensure that all necessary MemoryPhis have been inserted, and we only need to update them. The fixupDefs() implementation was also returning after updating a single access, which is not right. Fixes https://github.com/llvm/llvm-project/issues/47875. Fixes https://github.com/llvm/llvm-project/issues/117157. Fixes https://github.com/llvm/llvm-project/issues/152998. Fixes https://github.com/llvm/llvm-project/issues/155161. Fixes https://github.com/llvm/llvm-project/issues/155184.
This patch defers resetting optimized accesses until all uses are replaced, to avoid invalidating the iterator. Closes https://github.com/llvm/llvm-project/issues/139103. Closes https://github.com/llvm/llvm-project/issues/139289. Closes https://github.com/llvm/llvm-project/issues/139308.
We can use *Set::insert_range to collapse:
for (auto Elem : Range)
Set.insert(E);
down to:
Set.insert_range(Range);
In some cases, we can further fold that into the set declaration.
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.