<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On 21 Mar 2017 10:06 am, "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="quoted-text">
<p><br>
</p>
<div class="m_8454473520877474366moz-cite-prefix">On 03/21/2017 08:45 AM, Hubert Tong
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>This question was explored in an other context here:<br>
<a href="http://sourcerytools.com/pipermail/cxx-abi-dev/2013-January/002544.html" target="_blank">http://sourcerytools.com/<wbr>pipermail/cxx-abi-dev/2013-<wbr>January/002544.html</a><br>
</div>
</div>
</blockquote>
<br></div>
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:
<a class="m_8454473520877474366moz-txt-link-freetext" href="https://itanium-cxx-abi.github.io/cxx-abi/abi.html#closure-types" target="_blank">https://itanium-cxx-abi.<wbr>github.io/cxx-abi/abi.html#<wbr>closure-types</a>)
the layout must be fixed (because it must be consistent across
translation units).<br>
<br>
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)).</div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><font color="#888888"><br>
-Hal</font><div class="elided-text"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>-- HT<br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Mar 21, 2017 at 9:03 AM, Hal
Finkel 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Richard, Chandler, John, et al.,<br>
<br>
"Quick" question: What aspects, if any, of a C++ lambda
(e.g. size, layout, alignment) leak into the ABI or are
(potentially) semantically visible?<br>
<br>
Context...<br>
<br>
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.<br>
<br>
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.<br>
<br>
John, I'm curious about how this might apply to Objective C
blocks as well.<br>
<br>
Thanks again,<br>
<br>
Hal<span class="m_8454473520877474366HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Hal Finkel<br>
Lead, Compiler Technology and Programming Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</font></span></blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<pre class="m_8454473520877474366moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div></div>
</blockquote></div><br></div></div></div>