220 21365 article Path: news.gmane.org!not-for-mail From: Gor Nishanov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Resumable expressions p0114r0 vs async/await P0057R0 Date: Tue, 6 Oct 2015 08:57:10 -0700 (PDT) Lines: 165 Approved: news@gmane.org Message-ID: References: <639f0012-8cb4-4db3-82a6-8d042a3497f9@isocpp.org> <401aa118-ed0b-4c7b-92cf-3fbd706eff9d@isocpp.org> <1d15dbc4-e0c1-4df1-86db-014e11f14d26@isocpp.org> <1bf00a8f-5f20-43de-a319-2712ab34eafd@isocpp.org> <36f46c03-b1f1-4230-b686-a7a9a1c491cb@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6045_1744045774.1444147030396" X-Trace: ger.gmane.org 1444147038 27124 80.91.229.3 (6 Oct 2015 15:57:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Oct 2015 15:57:18 +0000 (UTC) Cc: german.diago@hubblehome.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC47RF4IW4GRBV66Z6YAKGQEYU3WIJI@isocpp.org Tue Oct 06 17:57:15 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZjUc4-00027F-UG for gclcip-std-proposals@m.gmane.org; Tue, 06 Oct 2015 17:57:13 +0200 Original-Received: by ioiz6 with SMTP id z6sf357265899ioi.2 for ; Tue, 06 Oct 2015 08:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=Q9Lk501W0fd1MLPh+k4wUQgzMdmtEpxqgW22x5vk/bk=; b=nxdNnw+qkLyyNx0fsk/h1kpNlcsQ50Kj0zEKggZMW8U0n9OohXTVYFcZ/VlTor4RIt hsJJFJ0e1WhbCJMiLmxZeBKINX3mPF0tduDz0DDYqK9xQGPv+myvT3dgbRcUGpYmsJtE gg4LC1miebbV5oATsdgrbJL5GsmeZCCa0u/T+A0NSOo5uwDugV4hcCHzJJe3OSM6nTMl EE5ojp22rsrq8RSw2y2/bNu7WbjSiCkCtWMpagud5oHgzyCGhTHo0rRJQxQQn97O7DpV yui4aBGrLwwdBwwdUlwnN121ZgI0UM5k9T4lBITCMwJzFdNt8VTtweiBCrkeTtAPpABW Eo/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=Q9Lk501W0fd1MLPh+k4wUQgzMdmtEpxqgW22x5vk/bk=; b=lHPOkNvyQINUn6KuoqITUoDaVa9eFBLVq0KSVZjsT4iRH27DRa18ATjdqRSglJ4Rtx IS/2xYo1JyABwK2wCY0gPoEFOqKLCT73DBd0+akdXnReEwR0rm083u0+dm/arcbGFDI8 wUunFxyGxJypo+fR7TyB4BDsHpmO2sYThU/H6P/g6/gfdpmaDImUKbQL5et9+2fc/Tre 2pIGWxCpfa3l+GMTX2V94zzualDh9+dXfIdkJRP3y+rEWP7UgEzPjp6LbT/ha1/pKygL S6eo5Dalor2CX/R3rE/qIqVESY6js6AmhMTiSRF/O8EqboqQBGJqe0404oiED8IkULGs atKA== X-Gm-Message-State: ALoCoQnBbgWhPjH4/nxWhpjQVUbKem/Di/Fo2iRzCHATcfM+Xz/ocoSgoMjQTd80RFJPGfTFrktm X-Received: by 10.50.36.104 with SMTP id p8mr12401480igj.0.1444147031894; Tue, 06 Oct 2015 08:57:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.225.97 with SMTP id rj1ls1533835igc.30.gmail; Tue, 06 Oct 2015 08:57:11 -0700 (PDT) X-Received: by 10.50.66.205 with SMTP id h13mr218551igt.10.1444147030981; Tue, 06 Oct 2015 08:57:10 -0700 (PDT) In-Reply-To: X-Original-Sender: GorNishanov@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:21365 Archived-At: ------=_Part_6045_1744045774.1444147030396 Content-Type: multipart/alternative; boundary="----=_Part_6046_333429548.1444147030396" ------=_Part_6046_333429548.1444147030396 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, October 6, 2015 at 7:57:15 AM UTC-7, Nicol Bolas wrote: > > How exactly does std::experimental::generator accomplish that? How can= =20 > the object know that it is contained entirely in this way? After all, the= =20 > promise type is what holds the state, and therefore the promise has to=20 > decide whether to statically or dynamically allocate memory, as well as h= ow=20 > to handle the forwarding to the function to be resumed. > There are only two magic types in this proposal. coroutine_traits, which=20 let the compiler figure out which promise_type describes the coroutine=20 semantics and coroutine_handle

which is synthesized by the compiler to= =20 allow resumption and destruction of the coroutine. If you look at the implementation of coroutine_handle in=20 , you will notice the following two members: void coroutine_handle::resume() { _coro_resume(_Ptr); } void coroutine_handle::destroy() { _coro_destroy(_Ptr); } _coro_resume and _coro_destroy are intrinsics that are implemented in our= =20 optimizer. After inlining, in the main, optimizer will observe the=20 following sequence: $fp =3D _coro_alloc_elision() ? alloca(_coro_frame_size()) : operator new= =20 (_coro_frame_size()); // frame size of hello$ coroutine bla _coro_resume($fp) bla _coro_destroy($fp); <-- here Now optimizer can reason about the lifetime and also to which function=20 _coro_resume($fp) and _coro_destroy($fp) go.=20 Since in this example, $fp does not escape. Optimizer replaces=20 _coro_alloc_elision with 1, thus, allocation is done via alloca(constant)= =20 which optimizer makes into a normal automatic variable. _coro_resume and=20 _coro_destroy are replaced with direct calls to hello$resume_coro, which=20 after inlining will lead to what I showed in my previous post. I talked to Clang implementers and they are planning to add this=20 optimization too. Note that it is explicitly allowed by=20 P0057/[dcl.fct.def.coroutine]/8 A coroutine *may* need to allocate memory= =20 to store objects with automatic storage duration local to the coroutine. *If so*, it shall obtain the storage by calling an=20 allocation function (3.7.4.1). The allocation function=E2=80=99s name is looked up in the scope of the pro= mise=20 type of the coroutine. If this lookup fails to find the name, the allocation function=E2=80=99s na= me is=20 looked up in the global scope... In other words, when allocation is needed, here is how the compiler figures= =20 out what allocation functions to use. But, if hte compiler does not need to= =20 allocate, it does not have to. --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_6046_333429548.1444147030396 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tuesday, October 6, 2015 at 7:57:15 AM UTC-7, N= icol Bolas wrote:
How exa= ctly does std::experimental::generator<T> accomplish that? How c= an the object know that it is contained entirely in this way? After all, th= e promise type is what holds the state, and therefore the promise has to de= cide whether to statically or dynamically allocate memory, as well as how t= o handle the forwarding to the function to be resumed.

There are only two magic types in this proposal= .. coroutine_traits, which let the compiler figure out which promise_type de= scribes the coroutine semantics and coroutine_handle<P> which is synt= hesized by the compiler to allow resumption and destruction of the coroutin= e.

If you look at the implementation of coroutine_= handle in <experimental/resumable>, you will notice the following two= members:

void coroutine_handle::resume() { _coro_= resume(_Ptr); }

void coroutine_handle::destroy() { _coro_destroy(_Ptr); }


_coro_resume and _coro_destroy are intrinsic= s that are implemented in our optimizer. After inlining, in the main, optim= izer will observe the following sequence:

$fp =3D = _coro_alloc_elision() ? alloca(_coro_frame_size()) : operator new (_coro_fr= ame_size()); // frame size of hello$ coroutine
bla
_cor= o_resume($fp)
bla
_coro_destroy($fp); <-- here
=

Now optimizer can reason about the lifetime and also to= which function _coro_resume($fp) and _coro_destroy($fp) go.
Sin= ce in this example, $fp does not escape. Optimizer replaces _coro_alloc_eli= sion with 1, thus, allocation is done via alloca(constant) which optimizer = makes into a=C2=A0normal automatic variable. _coro_resume and _coro_destroy= are replaced with direct calls to hello$resume_coro, which after inlining = will lead to what I showed in my previous post.

I = talked to Clang implementers and they are planning to add this optimization= too. Note that it is explicitly allowed by

P0057/[dcl.fct.def.coroutine]/8 A coroutine may need to allocate memory to store objects= with automatic storage duration local
to the coroutine. If so, it shall obtain the storage by calling an = allocation function (3.7.4.1).
The allocation function=E2=80=99s name is= looked up in the scope of the promise type of the coroutine.
If this lo= okup fails to find the name, the allocation function=E2=80=99s name is look= ed up in the global
scope...


In other words, when allocation is needed, here i= s how the compiler figures out what allocation functions to use. But, if ht= e=C2=A0compiler does not need to allocate, it does not have to.
<= /font>

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_6046_333429548.1444147030396-- ------=_Part_6045_1744045774.1444147030396-- .