Wei Mi via llvm-dev
2017-Apr-28 18:29 UTC
[llvm-dev] [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.
Daniel Berlin via llvm-dev
2017-Apr-28 19:00 UTC
[llvm-dev] [MemorySSA] A question about how to update the MemorySSA when we call RecursivelyDeleteTriviallyDeadInstructions
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.>> > Thanks, > Wei. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170428/0b31b4fc/attachment.html>
Wei Mi via llvm-dev
2017-Apr-28 19:19 UTC
[llvm-dev] [MemorySSA] A question about how to update the MemorySSA when we call RecursivelyDeleteTriviallyDeadInstructions
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. > >