[MemorySSA] A question about how to update the MemorySSA when we call RecursivelyDeleteTriviallyDeadInstructions

When we erase a memory access instruction, existing passes using
memory ssa like GVN, NewGVN, GVNHoist and EarlyCSE uses
MemorySSAUpdater to do the update before the instruction is erased.

However, if we call llvm::RecursivelyDeleteTriviallyDeadInstructions
to find out dead instruction recursively and memory access
instructions may be erased inside the recursive process, we need a way
to update MemorySSA for those instructions. Note MemorySSA update
should be done before the instruction is erased.

Is it acceptable to have an API with MemorySSAUpdater as a param, or
it is better for MemoryUseOrDef to have a callback value handler to do
the update transparently, or there are better ways to be suggested.

Thanks,
Wei.

When we erase a memory access instruction, existing passes using
memory ssa like GVN, NewGVN, GVNHoist and EarlyCSE uses
MemorySSAUpdater to do the update before the instruction is erased.

However, if we call llvm::RecursivelyDeleteTriviallyDeadInstructions
to find out dead instruction recursively and memory access
instructions may be erased inside the recursive process, we need a way
to update MemorySSA for those instructions. Note MemorySSA update
should be done before the instruction is erased.

Is it acceptable to have an API with MemorySSAUpdater as a param,

I think so, that is what we do in other APIs.

or
it is better for MemoryUseOrDef to have a callback value handler to do
the update transparently,

For removal, the order of removal matters
Just like with regular IR, you must remove the uses (or ensure a single
value for arguments) for MemoryPhi nodes before trying to remove them.

Thus it would likely be easy to cause subtle to trigger bugs with a
callback handler.

or there are better ways to be suggested.

When we erase a memory access instruction, existing passes using
memory ssa like GVN, NewGVN, GVNHoist and EarlyCSE uses
MemorySSAUpdater to do the update before the instruction is erased.

However, if we call llvm::RecursivelyDeleteTriviallyDeadInstructions
to find out dead instruction recursively and memory access
instructions may be erased inside the recursive process, we need a way
to update MemorySSA for those instructions. Note MemorySSA update
should be done before the instruction is erased.

Is it acceptable to have an API with MemorySSAUpdater as a param,

I think so, that is what we do in other APIs.

or
it is better for MemoryUseOrDef to have a callback value handler to do
the update transparently,

For removal, the order of removal matters
Just like with regular IR, you must remove the uses (or ensure a single
value for arguments) for MemoryPhi nodes before trying to remove them.

Thus it would likely be easy to cause subtle to trigger bugs with a callback
handler.

or there are better ways to be suggested.

I see. Thanks for the explanation!

Wei.