[cfe-dev] Lambdas and the ABI?

[John McCall via cfe-dev]

> On Mar 22, 2017, at 1:31 PM, Reid Kleckner <rnk at google.com> wrote:
> On Tue, Mar 21, 2017 at 9:01 PM, John McCall via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> 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.
> 
> 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:
> 
> 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.

Very good point.

> 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.
> 
> #include <memory>
> void may_throw(int);
> void foo() {
>   std::unique_ptr<int> p(new int(42));
>   may_throw(*p);
> }
> 
> 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.

It's okay for optimizations to only apply to "special cases", especially when those special cases are likely to be dominant in practice.  Optimizing lambdas would absolutely be worthwhile even if we had to not apply the optimizations to lambdas in inline functions.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170322/67d1b424/attachment.html>