[llvm-dev] [MemorySSA] A question about how to update the MemorySSA when we call RecursivelyDeleteTriviallyDeadInstructions (original) (raw)
Wei Mi via llvm-dev llvm-dev at lists.llvm.org
Fri Apr 28 12:19:44 PDT 2017
- Previous message: [llvm-dev] [MemorySSA] A question about how to update the MemorySSA when we call RecursivelyDeleteTriviallyDeadInstructions
- Next message: [llvm-dev] Enable new inline cost heuristic for switch
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Apr 28, 2017 at 12:00 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
On Fri, Apr 28, 2017 at 11:29 AM, Wei Mi <wmi at google.com> wrote:
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.
Thanks, Wei.
- Previous message: [llvm-dev] [MemorySSA] A question about how to update the MemorySSA when we call RecursivelyDeleteTriviallyDeadInstructions
- Next message: [llvm-dev] Enable new inline cost heuristic for switch
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]