SimplifyCFG has many places that do this return simplifyCFG(BB, TTI, Options) || true; As far as I can tell this calls the global entry point for SimplifyCFG which creates a SimplifyCFGOpt object to call run(BB) on. So I think this means SimplifyCFG can create a new SimplifyCFGOpt object each time it recurses like this. I don't know how deep it goes in practice. The global entry point also has a 4th argument called LoopHeaders that is defaulted to nullptr. I think we lose the LoopHeaders pointer the first time we recurse because none of the recursive calls pass it along. Should we instead be recursing to the run function on the current SimplifyCFGOpt object? ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180926/4de83228/attachment.html>
Ping ~Craig On Wed, Sep 26, 2018 at 4:03 PM Craig Topper <craig.topper at gmail.com> wrote:> SimplifyCFG has many places that do this > > return simplifyCFG(BB, TTI, Options) || true; > > As far as I can tell this calls the global entry point for SimplifyCFG > which creates a SimplifyCFGOpt object to call run(BB) on. So I think this > means SimplifyCFG can create a new SimplifyCFGOpt object each time it > recurses like this. I don't know how deep it goes in practice. > > The global entry point also has a 4th argument called LoopHeaders that is > defaulted to nullptr. I think we lose the LoopHeaders pointer the first > time we recurse because none of the recursive calls pass it along. > > Should we instead be recursing to the run function on the current > SimplifyCFGOpt object? > > ~Craig >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181001/d2bb4591/attachment.html>
Craig Topper via llvm-dev <llvm-dev at lists.llvm.org> writes:> SimplifyCFG has many places that do this > > return simplifyCFG(BB, TTI, Options) || true; > > As far as I can tell this calls the global entry point for SimplifyCFG > which creates a SimplifyCFGOpt object to call run(BB) on. So I think this > means SimplifyCFG can create a new SimplifyCFGOpt object each time it > recurses like this. I don't know how deep it goes in practice. > > The global entry point also has a 4th argument called LoopHeaders that is > defaulted to nullptr. I think we lose the LoopHeaders pointer the first > time we recurse because none of the recursive calls pass it along.I agree, it looks like we're dropping this in the recursive calls.> Should we instead be recursing to the run function on the current > SimplifyCFGOpt object?Seems reasonable to me. I don't really see any downside to doing that, though I'm guessing there may be some bugs/behaviour change since this will fix the loop headers issue.