[cfe-dev] Lambdas and the ABI?

[Richard Smith via cfe-dev]

On 21 Mar 2017 10:06 am, "Hal Finkel" <hfinkel at anl.gov> wrote:


On 03/21/2017 08:45 AM, Hubert Tong wrote:

This question was explored in an other context here:
http://sourcerytools.com/pipermail/cxx-abi-dev/2013-January/002544.html


Very interesting, thanks! So the conclusion was that, " The ABI will need
to specify the layout of closure types with weak linkage." In some cases
(enumerated here: https://itanium-cxx-abi.github.io/cxx-abi/abi.html#
closure-types) the layout must be fixed (because it must be consistent
across translation units).

I imagine that size/alignment might also need to be fixed in cases where
the source program explicitly depends on them (e.g. doing sizeof(lambda),
new auto(lambda)).


I don't think that's necessary for lambda types that do not escape a single
TU. But obviously a portable program should avoid depending on the size or
alignment of a closure type.


 -Hal



-- HT

On Tue, Mar 21, 2017 at 9:03 AM, Hal Finkel via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi Richard, Chandler, John, et al.,
>
> "Quick" question: What aspects, if any, of a C++ lambda (e.g. size,
> layout, alignment) leak into the ABI or are (potentially) semantically
> visible?
>
> Context...
>
> We're investigating late lowering/outlining schemes to improve code
> generation for OpenMP and other parallel programming models. One important
> advantage of outlining late is that the IR-level optimizer still has access
> to the pointer-aliasing and loop information from the containing function.
> There are natural benefits to C++ lambdas as well. Lambdas that are used
> "in place" (i.e. only have one call site) should always be inlined, so the
> issues don't come up there, but for lambdas that have multiple call sites,
> or worse, escape (via std::function or some other type-erasure mechanism),
> we can get suboptimal optimization results for the body of the lambda. It
> would seem sad to fix this for OpenMP but not for lambdas.
>
> However, optimizing before outlining could mean changes in what variables
> need to be captured (not semantically, but at the IR level), and so I'd
> like to think through what would constrain the optimizer's freedom to act
> in this regard.
>
> John, I'm curious about how this might apply to Objective C blocks as well.
>
> Thanks again,
>
> Hal
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>


-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170321/18c93fd0/attachment.html>