<div dir="ltr">Ping<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 26, 2018 at 4:03 PM Craig Topper <<a href="mailto:craig.topper@gmail.com">craig.topper@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>SimplifyCFG has many places that do this</div><div><br></div><div>return simplifyCFG(BB, TTI, Options) || true;<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Should we instead be recursing to the run function on the current SimplifyCFGOpt object?</div><br clear="all"><div><div dir="ltr" class="m_-1303821846511996115gmail_signature">~Craig</div></div></div></div>
</blockquote></div>