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 Topper via llvm-dev <llvm-dev@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.
Any chance to get rid of this kind of recursion entirely? If this is
too much work, reusing the same pass instance instead of creating a
new one sounds appropriate to me.