<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 21, 2017 at 9:01 PM, John McCall via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">3. We know exactly when the inner function will be called and it can be fit into the outer function's CFG.  This is true of some OpenMP features and some very specific Swift features.<br>
<br>
We can still do normal data-flow and control-flow analyses between the outer and inner functions; the only constraint is that we (probably) have to treat the beginning and end of the inner function as opaque barriers.  So the unlowered function looks something like:</blockquote><div><br></div><div>I'd also throw in that our implementation of MSVC EH is a good example of this type of inner function outlining in LLVM. The token-producing block leader and terminator instructions create single-entry single-exit regions that we can outline into funclets as part of CodeGen.</div><div><br></div><div>By keeping the funclets in the normal CFG of the parent function, we are able to SROA aggregates with destructors and do things like heap-to-stack conversion of std::unique_ptr.</div><div><br></div><div><div>#include <memory></div><div>void may_throw(int);</div><div>void foo() {</div><div>  std::unique_ptr<int> p(new int(42));</div><div>  may_throw(*p);</div><div>}</div></div><div><br></div><div>Getting back to Hal's original question, I think that these kinds of optimizations are impossible for C++ lambdas. They frequently appear in headers and it's really easy to leak the class type with decltype and auto, and that class definition better be the same across all TUs.</div></div></div></div>