From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2092.outbound.protection.outlook.com [40.107.223.92]) by sourceware.org (Postfix) with ESMTPS id 728E53858D34 for ; Sat, 18 Sep 2021 09:38:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 728E53858D34 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ga8nB0kJN6iawlrDgqE4/zt21o72ZIfxdJGMIOZPld92XZXYpBpjBGKdjx2DL8qZnl68YsvZirRGZIZjKogCrBf32uVuPHT8BiSoXYv4M7mmLHHqy2lD/C7tmxJlDu00RoU5v523w0cFMgC1qowlz1Y75TK5gn1nvC2nkV0dki3z3V9J1VXCJNe7aFOz9Q0QHtyk7u4yJeVqgVy0JKq4F/x4bzS9crd5dtKBiQEuc/uoxBfsrbCpCz3CaqyvuhNqjoYUKjZY0bGyfQz2PtgAwilArnvg5Pwub9RkJ5YipaUTYX16hWOPijlD8H/RC6PkJ0NazAPSWbrx0HMk1gO8FQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TN8scWpXTXPA3sM5JroiFPkD/fqkvrM3ro5BTmObruA=; b=KPBYghYR1xNLUf+ySQ+g3+t2E5E97MfQ5YDldcbRDIwAr/SLoXX4eXOwaQpXGA+Cz7khYv5wN9ffcSGV4a/Nv7qFPmfDhB4Dz63gpMJ/pg+XcqG1InAqTDwxUPq9N0M3aPc3iQBpAdBIaGJXwz1EF7DRXapNqCyiYG6ydOm5G2tXWwG7dY/ATbunfoXW3niQGuJsU7jbRNKDqYYXZWaYDEe91XSLTTrkpPdgQRqChe15b5RrdOLL7FOq5gdnoWlRIVdGf0vk5sKJjYJLjxUD4bwTS6cwIhebS2eB5+s4oJKZ2dZntM03Ef4OZH6ZqOIoj/NaqoXliJlSH7Q1I0FNAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=os.amperecomputing.com; dmarc=pass action=none header.from=os.amperecomputing.com; dkim=pass header.d=os.amperecomputing.com; arc=none Received: from SN6PR01MB4958.prod.exchangelabs.com (2603:10b6:805:c1::15) by SN6PR01MB4832.prod.exchangelabs.com (2603:10b6:805:db::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14; Sat, 18 Sep 2021 09:38:39 +0000 Received: from SN6PR01MB4958.prod.exchangelabs.com ([fe80::3ce8:b43d:e19b:e1af]) by SN6PR01MB4958.prod.exchangelabs.com ([fe80::3ce8:b43d:e19b:e1af%3]) with mapi id 15.20.4523.018; Sat, 18 Sep 2021 09:38:39 +0000 From: Feng Xue OS To: Jason Merrill , Jan Hubicka , "mjambor@suse.cz" , Richard Biener , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH/RFC 1/2] WPD: Enable whole program devirtualization Thread-Topic: [PATCH/RFC 1/2] WPD: Enable whole program devirtualization Thread-Index: AQHXqtX6Y9VMzNA8oEOQa6q1OMzPrKum8duAgACJUCWAAdJJAIAAK6x3 Date: Sat, 18 Sep 2021 09:38:39 +0000 Message-ID: References: <30e81796-15a7-bdf5-0c75-1ab882262e3a@redhat.com> <59eb3921-a948-613f-cf47-96e764626e42@redhat.com> In-Reply-To: <59eb3921-a948-613f-cf47-96e764626e42@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: e639c1ec-86e8-79a2-f7bb-f2036bd09cfb x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e14c519a-ba33-4854-a088-08d97a881893 x-ms-traffictypediagnostic: SN6PR01MB4832: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NpF7WK+cXWPyeaKo6rp0pO6h78kGchTw+1+hVyVhC/12RP2Az7RR2T12R41vZ7fjPYbn29dUD5Byqp2JO8DN6kTiBgXZ8Dacko8KBNljZB+eibDLfLQrIZ/xXHAv7VNp0go0KIbVeE771ba2H+gU/y5lDDx3+auYMl7Gf9zdoUGrZd7CqD1ixuJe1EsxI0lKRI8snLez5sNiUIlxQWggmAlQqbnwTEKTEe316gXmAQq5golsZXAIHiOR8Ef65KssygwFVaJwwLPi0I4s7e/eZw42Pj00jaexMU+6hRiRqQKN94nyXT+iBP6nNoC/fQW7DP67RskFZMWXrhOVH0wE4x5GGuehW4iyA7GSWmuVUQkzsBHtJLrr7zTgViQDAzjtpKmnBX+EFifGBlQhYlSZNGEO8NuaM/+oayyDNTG2+93fm/gOY0JUX7lh+V+GuhheoZjDqB9JzoIDmdBIZK2q26itRo5EOUgSmm+SnfgWuh2gUXoKmzrWp250Y2xKx1GBMsXAT88vHNq8/szAIC9stUHm50KSWsjAoNCCPu8+BhN+/FJJ3yaUtrqnaGkAeKtIibr+8WDf6Sq6lA49J8G6h4ZvgWC4jFLe2aX8Gv6l/+dO+AxRgqjQ2tBDZrY+28fzYuSzVvO760pTg57/feoXrcFN5/cC7exiykP7NGUUzijiPxATNOF63flRUJZqhpXY5374dUKiTq1n3XBnjrzwHAO1Z/mbk18OqZxy/5bj2xlctmoqIv+rcYDGRJtBZ9spq6ifwUbwIp0fPMQJaekIdC4mDlwPES9lYoZRwdyFpYo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR01MB4958.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(366004)(39850400004)(346002)(396003)(38100700002)(91956017)(66446008)(38070700005)(76116006)(8936002)(64756008)(6506007)(66946007)(2906002)(26005)(478600001)(53546011)(122000001)(9686003)(66556008)(83380400001)(71200400001)(8676002)(33656002)(66476007)(5660300002)(86362001)(186003)(55016002)(966005)(52536014)(7696005)(316002)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?PDJqOJgYWt3FGMMsjGHLlyYVtZ/f9X2axysNPanP4FGnD7G30j2wkaSNub?= =?iso-8859-1?Q?wyzUoM7uJi77vYLrB7gB7ggBDch2aUi7NqFm/8sCjghvu6XMcHdVQXBlT8?= =?iso-8859-1?Q?72a45p0Ia1F12nMXvNTWI0NOQWanj5lp0RuVuB+/1JbYa4Ed1/z29qOEG8?= =?iso-8859-1?Q?0cTxSS4uaeoDgvINWnsYhjXnVJpy0FoFcmPntgvzMyeLONnZRXK+1GQflN?= =?iso-8859-1?Q?lT3UpjuXCIzyXy3t2YywurE7vgmCjQswc8eVfyeFJ+vilgBdUIL5RxHTFL?= =?iso-8859-1?Q?jz25cDo6FFhZY5mo0QXPhPTGTUjTVwI1V2G0xi4CnL22EJAk+xI+e4Rl9d?= =?iso-8859-1?Q?PtrLzVrOMaZr/xExSRhQBGokxjkdEO9N7XkF84XoxQijvBAyH81MtSijRr?= =?iso-8859-1?Q?E4B5ahve6F4PRFKqWyG+hEK4Cj2amhaMk6AuC3NEYBbIBQ1Q1lH0n2UXyW?= =?iso-8859-1?Q?iJgJ+y6UunrBfXYfDEPESHZ7Dec8oSw9aB8aPurxda24+DP7hgc9WYdTsJ?= =?iso-8859-1?Q?Ks5ZJQSfirkp8sPg0OJkV2ZvR3ymJbUE8Ipx46VfzFvpe8bggx8lpzareD?= =?iso-8859-1?Q?opsAqfO6VBMj4C/h7cjZ5UShk/CqoXvnCXLYQ31qRncmgaJcHartpqvqWj?= =?iso-8859-1?Q?scEJyjY5l24nctuP6+zyZuyE2lVRJTjG126ol73xyXINMgAkOhlNLfYX2i?= =?iso-8859-1?Q?p9e4tS+ShGXCBEkXkkOB9uUWE+SuO+2uG44NAZzsmPTo3zKFZgaeAL1iFl?= =?iso-8859-1?Q?tgCtgIWRFeYffUrn9QJ2jh/YInbdqt0OzRhBSPMC66qt3Q4IsdiVUYgZP2?= =?iso-8859-1?Q?UfuT5yW8zBIwIaCFlFfEKikPsPkNGDaZUEqAQ49YXe+VFaYyhgcQZOACsm?= =?iso-8859-1?Q?yNlMN+L6L0RoKDS5rowB5MIg26D6XyiQhTty0q8j9fD8arYuUmPyoJWJnl?= =?iso-8859-1?Q?sHMPNnsSO4Pf2rwk513joscvLXsB3Ggg0l+pa49nC7m4jdMj9IXOyK2D7M?= =?iso-8859-1?Q?989UTah1gruQ83p5ThhXj2lE1+6fucqwCpt38annknYu0y+LRzwpq7jKLS?= =?iso-8859-1?Q?QJiNGMLl078tsfvgPr5//R+z/StLNeVPWPSIGtpoTsPK/vKh3MdrLcY3sw?= =?iso-8859-1?Q?BEa149e91wdT1VQsb1Fien12WiecBVDxlMAwrYdzGF0OEkmCFC2R4CtTyR?= =?iso-8859-1?Q?MJuQQNCmDYvyurl1td14HGQYS7FBLYmjymL2hoR5wMBPZm3KgjBQgShXOw?= =?iso-8859-1?Q?7DTslcyLcbparvTgXe+JyON/vy92QfjxR+dhK0AY1WN1memKiZGIqkPJ92?= =?iso-8859-1?Q?yOxM6rFwsNvuTqfZBtEFb4kX/lgR3GCVUmehxGb8yAIDB/M=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: os.amperecomputing.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR01MB4958.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: e14c519a-ba33-4854-a088-08d97a881893 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2021 09:38:39.5155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CKKDZ0soDjoKkcccREs1nV804fhAhQ2Ht6xOPSNF6WUJAEeqtk3C0Gb9Lv1Nu/yXLoSf0WG/NEJlGnVmFIlPE+iDebQCfoc7ep5zOTPzRMU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB4832 X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Sat, 18 Sep 2021 09:38:44 -0000 >On 9/16/21 22:29, Feng Xue OS wrote:=0A= >>> On 9/16/21 05:25, Feng Xue OS via Gcc-patches wrote:=0A= >>>> This and following patches are composed to enable full devirtualizatio= n=0A= >>>> under whole program assumption (so also called whole-program=0A= >>>> devirtualization, WPD for short), which is an enhancement to current= =0A= >>>> speculative devirtualization. The base of the optimization is how to= =0A= >>>> identify class type that is local in terms of whole-program scope, at= =0A= >>>> least those class types in libstdc++ must be excluded in some way.=0A= >>>> Our means is to use typeinfo symbol as identity marker of a class sinc= e=0A= >>>> it is unique and always generated once the class or its derived type= =0A= >>>> is instantiated somewhere, and rely on symbol resolution by=0A= >>>> lto-linker-plugin to detect whether a typeinfo is referenced by regul= ar=0A= >>>> object/library, which indirectly tells class types are escaped or not.= =0A= >>>> The RFC at https://gcc.gnu.org/pipermail/gcc/2021-August/237132.html= =0A= >>>> gives more details on that.=0A= >>>>=0A= >>>> Bootstrapped/regtested on x86_64-linux and aarch64-linux.=0A= >>>>=0A= >>>> Thanks,=0A= >>>> Feng=0A= >>>>=0A= >>>> ----=0A= >>>> 2021-09-07 Feng Xue =0A= >>>>=0A= >>>> gcc/=0A= >>>> * common.opt (-fdevirtualize-fully): New option.=0A= >>>> * class.c (build_rtti_vtbl_entries): Force generation of typein= fo=0A= >>>> even -fno-rtti is specificied under full devirtualization.=0A= >>>=0A= >>> This makes -fno-rtti useless; rather than this, you should warn about= =0A= >>> the combination of flags and force flag_rtti on. It also sounds like= =0A= >>> you depend on the library not being built with -fno-rtti.=0A= >>=0A= >> Although rtti is generated by front-end, we will remove it after lto sym= tab=0A= >> merge, which is meant to keep same behavior as -fno-rtti.=0A= >=0A= > Ah, the cp/ change is OK, then, with a comment about that.=0A= >=0A= >> Yes, regular library to be linked with should contain rtti data, otherwi= se=0A= >> WPD could not deduce class type usage safely. By default, we can think= =0A= >> that it should work for libstdc++, but it probably becomes a problem for= =0A= >> user library, which might be avoided if we properly document this=0A= >> requirement and suggest user doing that when using WPD.=0A= >=0A= > Yes, I would expect that external libraries would be built with RTTI on= =0A= > to allow users to use RTTI features even if they aren't used within the= =0A= > library. But it's good to document it as a requirement.=0A= >=0A= >> + /* If a class with virtual base is only instantiated as=0A= >> + subobjects of derived classes, and has no complete object= in=0A= >> + compilation unit, merely construction vtables will be inv= olved,=0A= >> + its primary vtable is really not needed, and subject to b= eing=0A= >> + removed. So once a vtable node is encountered, for all= =0A= >> + polymorphic base classes of the vtable's context class, a= lways=0A= >> + force generation of primary vtable nodes when full=0A= >> + devirtualization is enabled. */=0A= >=0A= > Why do you need the primary vtable if you're relying on RTTI info?=0A= > Construction vtables will point to the same RTTI node.=0A= =0A= At middle end, the easiest way to get vtable of type is via TYPE_BINFO(type= ),=0A= it is the primary one. And WPD relies on existence of varpool_node of the= =0A= vtable decl to determine if the type has been removed (when it is never=0A= instantiated), so we will force generation of vtable node at very early sta= ge.=0A= Additionally, construction vtable (C-in-D) belongs to the class (D) of comp= lete=0A= object, not the class (C) of subobject actually being constructed for, it i= s not=0A= easy to correlate construction vtable with the subobject class (C) after fr= ont=0A= end.=0A= =0A= >=0A= >> + /* Public class w/o key member function (or local class in a pub= lic=0A= >> + inline function) requires COMDAT-like vtable so as to be shar= ed=0A= >> + among units. But C++ privatizing via -fno-weak would introdu= ce=0A= >> + multiple static vtable copies for one class in merged lto sym= bol=0A= >> + table. This breaks one-to-one correspondence between class a= nd=0A= >> + vtable, and makes class liveness check become not that easy. = To=0A= >> + be simple, we exclude such kind of class from our choice list= .=0A= >=0A= > Same question. Also, why would you use -fno-weak? Forcing multiple=0A= > copies of things we're perfectly capable of combining seems like a=0A= > strange choice. You can privatize things with the symbol visibility=0A= > controls or RTLD_LOCAL.=0A= =0A= We expect that user does not specify -fno-weak for WPD. But if=0A= specified, we should correctly handle that and bypass the type. And=0A= indeed there is no need to force generation of vtable under this=0A= situation. But if vtable is not keyed to any compilation unit, we might=0A= never have any copy of it in ordinary build, while its class type is=0A= meaningful to whole-program analysis, such as an abstract root class.=0A= =0A= Thanks,=0A= Feng=