From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWPoH-0004ua-97 for qemu-devel@nongnu.org; Thu, 18 Feb 2016 09:44:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWPoD-000210-Vc for qemu-devel@nongnu.org; Thu, 18 Feb 2016 09:44:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54005) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWPoD-00020u-Np for qemu-devel@nongnu.org; Thu, 18 Feb 2016 09:43:57 -0500 References: <1455778109-6278-1-git-send-email-eblake@redhat.com> <1455778109-6278-7-git-send-email-eblake@redhat.com> <87io1mdsrj.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <56C5D8AC.60302@redhat.com> Date: Thu, 18 Feb 2016 07:43:56 -0700 MIME-Version: 1.0 In-Reply-To: <87io1mdsrj.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9VdelJ2OKvlGNGGNqc4xhX7AUeCuE3vFx" Subject: Re: [Qemu-devel] [PATCH v11 06/15] qapi: Visit variants in visit_type_FOO_fields() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Michael Roth This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9VdelJ2OKvlGNGGNqc4xhX7AUeCuE3vFx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/18/2016 06:58 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> We initially created the static visit_type_FOO_fields() helper >> function for reuse of code - we have cases where the initial >> setup for a visit has different allocation (depending on whether >> the fields represent a stand-alone type or are embedded as part >> of a larger type), but where the actual field visits are >> identical once a pointer is available. >> >> Up until the previous patch, visit_type_FOO_fields() was only >> used for structs (no variants), so it was covering every field >> for each type where it was emitted. >> >> Meanwhile, the code for visiting unions looks like: Maybe reword this to: Meanwhile, the previous patch updated the code for visiting unions to look like: >> The resulting diff to the generated code is a bit hard to read, >=20 > Mostly because a few visit_type_T_fields() get generated in a different= > place. If I move them back manually for a diff, the patch's effect > becomes clear enough: the switch to visit the variants and the > visit_start_union() guarding it moves from visit_type_T() to > visit_type_T_fields(). That's what the commit message promises. I debated about splitting out a separate patch so that the motion of visit_type_T_fields() is separate from the variant visiting, but it wasn't worth the effort. I'm glad you managed to see through the churn in the generated code. >> -def gen_visit_struct_fields(name, base, members): >> +def gen_visit_struct_fields(name, base, members, variants=3DNone): >=20 > Two callers: >=20 > * gen_visit_union(): the new code here comes from there, except it's no= w > completely guarded by if variants. Effect: generated code motion. >=20 > * gen_visit_struct(): passes no variants, guard false, thus no change. >=20 > I think the patch becomes slightly clearer if you make the variants > parameter mandatory. It'll probably become mandatory anyway when we > unify gen_visit_struct() and gen_visit_union(). You beat me to it - yes, I realized that after sending the series. We can either squash in the fix here to make variants mandatory (and gen_visit_struct() pass an explicit None, which disappears in the next patch), or squash in a fix to 7/15 to delete the '=3DNone'. Either way, I'm fine if you tackle that, if no other major findings turn up. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --9VdelJ2OKvlGNGGNqc4xhX7AUeCuE3vFx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWxdisAAoJEKeha0olJ0Nq6Z0H/RgXKM2MKeJ4VF3geu3ZuY0P cGsepRMf+MdFRGJXCYRQ14RO74osEpT6N5Ldgb/DnFEEDnTh2pvfGLd4xSIbeRW6 Uvc7OlwNXFmeTvKLIVdhBZojZkuc81zU7A/HU42xxy10ccKra5oEyTBRkLOo5csT byJE6+Ocs1wU4JLSQt12cWODZNJR0N/9YlSTR0fkqpQdF1SPTLN4ehuIe1FHxVtk nvzu+jMmU54EBHBBjBg1eGtNfuXe8QjU7uBgpH2M1QBgKq62UmPRoPpmcjGtvICG twB8dHfwHZrcBUe6Rpn4eZIGzFNuinF5ea8XggzCU3beybaW/3klOz9BQYOpE/M= =wFih -----END PGP SIGNATURE----- --9VdelJ2OKvlGNGGNqc4xhX7AUeCuE3vFx--