From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id 658E2385696B for ; Tue, 12 Jul 2022 15:14:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 658E2385696B Received: by mail-ej1-x635.google.com with SMTP id b11so14842580eju.10 for ; Tue, 12 Jul 2022 08:14:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-transfer-encoding :content-disposition; bh=5j8Jja5kLs2jh48TiaLfK8AGV2TK/7zdJb4m4JEyuTA=; b=bOKUDXSyuXAZYgqeXy20QW/30k6bxBWaHcd6lY20QuUSEjhZcEE06wu6ZugUC0e1Gr tHB+T1ypbDYfb8BKQUXfDhhoKciBy7vrurbNrilatVRj2qNTD65Bed9wvCIcKNZzSXer /yaxpyfkgJkJSTQPGukEtbWHLob4luFVeSwBcaKKoKOFsxKK13Qs93ZQJW3lmqYQ/IZx 76mX3RJlzI8Cc+bAEBtpfnaOkWQdeAgmyd5vZF+4XFoLYHzbLNlSxCJfKGKIa6Ydj/fe P0qCdXO6DtQp9J/OZSC8YzWE4qBsG0sf36vf7qwmQ43Nbu8SLZrYS0rXO2/qWreKqzu7 3DCA== X-Gm-Message-State: AJIora9E6XOi/SHESq7ZMknMj4AtaWzTEumbRusbNKTqywJgCEp+GEKV 19uDzkHs5IhrY+9tKLbq+vWPIa14V3jVGQ== X-Google-Smtp-Source: AGRyM1t3HG1uOW413CJxZpWFsRmxhrB5sK5CGt8ZE4+W1TDANRcv+Y7i2asyIbjOjB7OgByGsxvn4Q== X-Received: by 2002:a17:906:8a6c:b0:72b:3b4f:13b with SMTP id hy12-20020a1709068a6c00b0072b3b4f013bmr18190098ejc.14.1657638878092; Tue, 12 Jul 2022 08:14:38 -0700 (PDT) Received: from miso-desktop (ip-94-112-230-129.bb.vodafone.cz. [94.112.230.129]) by smtp.gmail.com with ESMTPSA id pv20-20020a170907209400b0072b3464c043sm3872978ejb.116.2022.07.12.08.14.37 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 12 Jul 2022 08:14:37 -0700 (PDT) Date: Tue, 12 Jul 2022 17:14:36 +0200 From: =?utf-8?Q?Michal_Jankovi=C4=8D?= To: Iain Sandoe Cc: GCC Patches Message-ID: <0334F8DB-C49F-4EB2-98C5-91A44A851F70@getmailspring.com> In-Reply-To: <236E416B-F744-42C1-806C-4701DB1BAB55@sandoe.co.uk> References: <236E416B-F744-42C1-806C-4701DB1BAB55@sandoe.co.uk> Subject: Re: [PATCH] c++: coroutines - Overlap variables in frame [PR105989] X-Mailer: Mailspring MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Status: No, score=1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2022 15:14:40 -0000 Hi Iain, Thanks for the reply, this is my first time contributing and I am looking forward to your input. One other related thing I would like to investigate is reducing the number of compiler generated variables in the frame, particularly =5FCoro=5Fdestroy=5Ffn and =5FCoro=5Fself=5Fhandle. =20 As I understand it, =5FCoro=5Fdestroy=5Ffn just sets a flag in =5FCoro=5Fresume=5Findex and calls =5FCoro=5Fresume=5Ffn; it should be po= ssible to move this logic to =5F=5Fbuiltin=5Fcoro=5Fdestroy, so that only =5FCoro=5F= resume=5Ffn is stored in the frame; this would however change the coroutine ABI - I don't know if that's a problem. The =5FCoro=5Fself=5Fhandle should be constructible on-demand from the fr= ame address. Do you have any advice / opinions on this before I try to implement it=3F= Michal On Jul 12 2022, at 4:08 pm, Iain Sandoe wrote: > Hi Michal, > =20 >> On 12 Jul 2022, at 14:35, Michal Jankovi=C4=8D via Gcc-patches >> wrote: >> =20 >> Currently, coroutine frames store all variables of a coroutine separat= ely, >> even if their lifetime does not overlap (they are in distinct >> scopes). This >> patch implements overlapping distinct variable scopes in the >> coroutine frame, >> by storing the frame fields in nested unions of structs. This lowers >> the size >> of the frame for larger coroutines significantly, and makes them more = usable >> on systems with limited memory. > =20 > not a review (I will try to take a look at the weekend). > =20 > but =E2=80=A6 this is one of the two main optimisations on my TODO - so= cool > for doing it. > =20 > (the other related optimisation is to eliminate frame entries for > scopes without any suspend > points - which has the potential to save even more space for code with > sparse use of co=5Fxxxx) > =20 > Iain > =20 >> Bootstrapped and regression tested on x86=5F64-pc-linux-gnu; new test = fails >> before the patch and succeeds after with no regressions. >> =20 >> PR c++/105989 >> =20 >> gcc/cp/ChangeLog: >> =20 >> * coroutines.cc (struct local=5Fvar=5Finfo): Add field=5Faccess=5Fpat= h. >> (build=5Flocal=5Fvar=5Fframe=5Faccess=5Fexpr): New. >> (transform=5Flocal=5Fvar=5Fuses): Use build=5Flocal=5Fvar=5Fframe=5Fa= ccess=5Fexpr. >> (coro=5Fmake=5Fframe=5Fentry=5Fid): New. >> (coro=5Fmake=5Fframe=5Fentry): Delegate to coro=5Fmake=5Fframe=5Fentr= y=5Fid. >> (struct local=5Fvars=5Fframe=5Fdata): Add orig, field=5Faccess=5Fpath= . >> (register=5Flocal=5Fvar=5Fuses): Generate new frame layout. Create ac= cess >> paths to vars. >> (morph=5Ffn=5Fto=5Fcoro): Set new fields in local=5Fvars=5Fframe=5Fda= ta. =20 >> =20 >> gcc/testsuite/ChangeLog: >> =20 >> * g++.dg/coroutines/pr105989.C: New test. >> =20 >> > =20 >