| Message ID | MN2PR21MB13923DBD9C353C2663B13132911F2@MN2PR21MB1392.namprd21.prod.outlook.com |
|---|---|
| State | New |
| Headers |
Return-Path: <gcc-patches-bounces~patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 216FC3857820 for <patchwork@sourceware.org>; Mon, 13 Jan 2025 21:47:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 216FC3857820 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=microsoft.com header.i=@microsoft.com header.a=rsa-sha256 header.s=selector2 header.b=EwCDcAE4 X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from CY4PR02CU008.outbound.protection.outlook.com (mail-westcentralusazlp170110003.outbound.protection.outlook.com [IPv6:2a01:111:f403:c112::3]) by sourceware.org (Postfix) with ESMTPS id A7C713858D38 for <gcc-patches@gcc.gnu.org>; Mon, 13 Jan 2025 21:46:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A7C713858D38 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=microsoft.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=microsoft.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A7C713858D38 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2a01:111:f403:c112::3 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1736804769; cv=pass; b=jlDCdOaJsEqwRDomycg98EyOUuUhlmoSgujLnG1yo5xR9Iz2c9vcZxqy8wNzxFvoVhfCfq/qXu3lJxp9nOd9MEjX1A7fCeY7XWNDQ/Phd6iPP0ybR3qdglxO35Q57z4joxm/CGa5LFU0N0gskTEuDf0TfRVG9UKhxMcTmAVgnWg= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1736804769; c=relaxed/simple; bh=TvX4aqsZ6xWpm5TBQKUhego7XL7qRwfp7IckOCZJrrg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=a/DZdpUveEyJt/FaQArqn2OZqNGd3jA54aWfZQcmlvSVJnPN2iPmYUyGG+2YlVpklrG2O0Ou0DE1414RGq7tChEbSvxx43HRI/ykKH3bMrR3sqD8dhhDwXMbo3YSMLlfcJn9bYKuaA4ZnzgqEbbStX5PGWlqYjmp1tRyxJjKv0A= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A7C713858D38 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SGM/OGmZDCXcU2wuCVljTh8/42LTpf/Aqdi2fBsfszF9+f8LaSR6K9QwKPF4QDHgEldEzNyuSTj5s5mczzIPL0YOs0Lsg6931R3juLzJJ1VzARO+K1FwZsX8c/a9+mVm2W/I2aZ5g9jKwR0KFDcOFSgz9y9I0NFgzHFPGIqn0Rsjc3d8VC+JZAVZ8F04Uiq4RjV6IvxECf5dzB6xgrnF1wTVzbyGQFLsUV/GFJJM5akcPVm8oYR9Aull1L9YqRCc7uuWSx7AtBCEPa6fnTD+A/SxgLiz84KNN5r6d9SHzijwMtH7B1GSp4dmoxi970tdJVT7zO7XfTRn5jLvnrb4Lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WiG1lXlny5CcRcfGEH1N754jTF3vjmQmqmd6AD/zLPg=; b=ZE5QHk3UaO0ur4tfGbqr2Mkr8UVKSJCMkh7WcHgbd4o+mj1FO5hBs6W0V7H9V1maLdCbwA3pWLEHGyixWXjTjnInpZwa8goL7ZqnG1HHmDqZmOnMiOPYHdk75Z5UrmV7avi4F4T0xB0ud2LxHbG2QVf2HULNq1zaa40opcgl1uLTVRMrH2QM/EGQW8k/YnXj+6ViE/+sYI5J94/vdLxWyQDN9Vmq7BWGuACYDbrl5cUaGe8jPZUBvHAw7en1+Qsviao8hfvknDTXZE79beC8bySJaaJAY2o+aXQMVfxZRFnO/LtNBGKJcShFLOjPflkWp7WoEZDkv/i7eXiHcLOTZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WiG1lXlny5CcRcfGEH1N754jTF3vjmQmqmd6AD/zLPg=; b=EwCDcAE4aLP37qCa6wOjQhMRtZ/4lhHhd9mujDk/d36/Izu4RbKYBWENQvtrNGLuOEfj9Vk/n+Wf6hy/u4ZL+5EEFA5+TOGhnsISECxI5ylMhkpJvMjUykMi6NoMCG9adVEdPuWd2TSI6yl9l0tdHvYjQKWZuOzB66JYpqRZ3SI= Received: from MN2PR21MB1392.namprd21.prod.outlook.com (2603:10b6:208:20a::16) by IA1PR21MB3688.namprd21.prod.outlook.com (2603:10b6:208:3e3::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.11; Mon, 13 Jan 2025 21:46:05 +0000 Received: from MN2PR21MB1392.namprd21.prod.outlook.com ([fe80::61d5:c009:afe6:3d16]) by MN2PR21MB1392.namprd21.prod.outlook.com ([fe80::61d5:c009:afe6:3d16%3]) with mapi id 15.20.8356.010; Mon, 13 Jan 2025 21:46:05 +0000 From: Eugene Rozenfeld <Eugene.Rozenfeld@microsoft.com> To: GCC-Patches-ML <gcc-patches@gcc.gnu.org>, Jan Hubicka <hubicka@ucw.cz>, "rvmallad@amazon.com" <rvmallad@amazon.com> Subject: [PATCH] Fix setting of call graph node AutoFDO count [PR116743] Thread-Topic: [PATCH] Fix setting of call graph node AutoFDO count [PR116743] Thread-Index: AdtmBBYRNcLCSsSCT8SA5gBktEs3eA== Date: Mon, 13 Jan 2025 21:46:05 +0000 Message-ID: <MN2PR21MB13923DBD9C353C2663B13132911F2@MN2PR21MB1392.namprd21.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=add51475-5bdf-48e0-99b5-7d8341884c65; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2025-01-13T21:41:29Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Tag=10, 3, 0, 1; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MN2PR21MB1392:EE_|IA1PR21MB3688:EE_ x-ms-office365-filtering-correlation-id: 99631a23-43c4-46e4-25e3-08dd341baeb4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|366016|376014|1800799024|10070799003|8096899003|38070700018; x-microsoft-antispam-message-info: eBrzDKY+T6Fzk8j8qpKnqK3CaEIsJGXI+p4qEMQjolqtx+so7kT48M4lkqaxCqDmHd4Q3CMbqJoujd4GkRzOH9CcYsIAaY1Md+xKJKS/ZbraRoX5w3nTJ2cfB6lFLjpz/v/0Dw0oiBSLeXWagF3Ck79d0bDRVISE3K+ZBcRvV2xlxPq9jn5Ok+kowf1BLitoy6wt5vVCahMXvzZ/9+psbnL2RWEgCjrOOmomgVnp222AahyPFYnFcJMJe+gidq2G4jivYFzgNTLgIIiOICIuZb75SIn7Cl/DENB0HiG0uAyO0kaSff9S6WIdlhT0rE2et/4YJgqPLgziOjFkT0lbbWu4K3WCffVRl/hCZn/MtC39wqWNqD5hifreWA326qB6km83JSKQQl6klxYD+gKuY8RFN9+5XZddahEe4rXDCL6FJod/nBU48vzSbLV7gvLDoEPLAw6PNcYrbf34KwwkvmZsONGfQyprYgVv+1vOzjcI/pQ7TUbSrUo85I8tFOWwe4JrCh4GMICumkCResWq9H7kLUUCv6/t5l9M2qG0qaTPhSCW8nb2eRtRjMs75LvEtDKSJvDKorP9AVvAaa345HQmw8nSD0p1zRrmq6YKEULqL2SWh9/v/4L2+gRDrc/cOXQf5CWR3p1m+xKGQriohyEkIJ9FZr4sOWUSfnrZH108+4BW1AhAhc4u/dkl5BPenXLl3dqyhyLxgmPE83agW47RPxSW4E7TC6p7awBsOKMj6KtFldFX6z5MZHQUCXHEoDmMOX+pclSmXmCoHowGjiZ1b5kiehjoKuSOCh3RHFEDaVla9dHR92MAZqccJlaUjR7/MQTut9CQ0l20Ue4VotS3oa7715sBUeKGJarmYxpevJTQxO6eNSWcFKRkPfHQrvyNxkS0NBRhy3e/Xuw5l7aSk/X0UQswZ+dDnuApMrn5mCE7gSGxAFGHK8+Sgp78nsfpgFNQp+TFVNQ5THBTh+NKyK6MUZZdZKfrMFDeaUqUp1W7rEFhmOIa1lMO58OrOQ3v/Co9Ta3X0tAco/XYoWzLLY71zftrfqFHwF7ISWXpK2HIdcc7TgKXBpg03gUjo8dlw2LB6LXCj0eGWZgVyypOsHyje8G/8kIxpAz3mye/C8fiqQXM8JlVykWc142oMy7SiubjZJ8OxyvvO19XZ4+x5jvkwIg0mtUtaO+g6BA+81T5xYm2v8EIdQrlFEjkIyMRyYeMvD7hPzcPjiuB3t6JwAvlVgfRFi2FSqpWirCVEWi4UgyqRpTcBceTZPbHJkQlWqrnRKEjmROnlBa4JoLmZ3L2Cvc1s//F8uEXhlJuwaz9pMNyXBi/HFt+cIYbkwcwlNQbHnKiiQ3zDACKViJVQtkXdAsvqqwMV9WeJIgI4Th9chsRHEUd7OyUGXwuSJJBVLzf6vNP4iGtPNgxcfByL9w8ga1XwyOzbu2PUOA+ANwYomTxAtENiWd/DzXL x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR21MB1392.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(376014)(1800799024)(10070799003)(8096899003)(38070700018); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: nfPC7T77lf1YRyW3owZxZ/WvZ19XWrPEVPRI3u9qjn9+bjxETH+3FtIlBICcSx4sOT45XM6vBPrB5xDoB+203lKs7duBGUctGeCkpnmtR5bgseB5vVrKTi5CC7WA0u5XD8N8uVtO6ZcIrXomPxcYDN0OPFDpW3j30wn0Bh3wu53eJrOa/lzE0pwY3km4+igPADOX44xaZBUP6aB3T8WsVku313hsOFUzxjkJUgsxDXqGrKFNiKFHl38q7B5Ga8znP/9SLINm5wrkKeIaa3UYXZcDmumAyJ5h/jKJWUjnSI7D7NM6U9s6nPvjGrwDVw6fBci7oJdeesfb77se7b3InaGl8dYrBGgFwKBfwBH1C2qvostVfpUHt4QalUEiWopYA/+VHnxF9f1BdnGZ4jLG3hGf8O9Cvyduj0cXtFLK9LFbRm4klPGowIt+kIJOO2YodL3L8fA+tHMlJ5JodKD9c3R1834Omgi2ZCjOYkaSqFYszRS60h17CaHhPgwNDForzWkkQjaaoYg+NNNVldvGdvQT1BU6xt9vtDKnPMwnbx06CKv+GYCEFLb3apoJ1jBtpWdN8/iJHdOK4ZX6tDV2CSg7A7tFC75kyJlPxYnBvsLd/qPRkf5qEc/aJCcPJTPNbUMiDL7SHVoYAmMOEYeYR8yekL6Et2VdgPJNvq0YEo2qrbMlYBHI738Dcq/fvNLEbKPH5skm/TmvYV/KQnwXTUqbGN+EIsjUQX8vPD30CtULR/aEf3Xi1UHuGp6P1C1qqg0wYULxk7HAN/U2j365/kzxm8iuT4ywJJOerq8HcXPEQH6QkA7zbwK8/syeZsrPjY8QnGQxhEKziNxT8AiUMbszbkDv1NvEeq2G14CgxKJTu6nH1PvsMp9ZWHIVXrA2lRjtTlwlPOzd4VfuUaOiVpKd5kb35S3CnSqU/Rg31FCrL5G+QJuw4EwIsCm80bCm9cwiGhylzxTSQ29RR5FhVNPqYktMcBCTn1Xogm+YuHJiWRTrbsn6RF758UvbfXis98nYMDUjYfiee5tbLFXA2o+9itSBQTm7unk+hObIl9YIu7WRNxdd1ejEeDT3Tz7okvaIljAqXtZB+vPV2JiBgXIsF3h3Ak+C1oWxWt8N1/o3KJEvAkc0habffMspaBxWAQ0Su2AmpC9C0jKvEHwz485beO4y1uz8djvym9S57XLsZShBxZorLh/WVZ32ZFEHB8IBcA1IUITtSOk9xRLWJksex2BjDcnmtoquCOAyxqXGe7Ue2jmGmcu94dhHtSb+ROjLybkUhqvalhq6fuh02EziH6BDUp8WTSDKcdCI7/LNhxOt4/Ot9pUzRavOSMqKOPPFAPS/41F4mnvOXMXGjzmp/yWTkGkKMlyY8i9up+nSVdRe152PPk/2E2i/qjGs42ccn/2R9H2YOJWWQuR1cCGxQPUbeEhw8cZdXCJn3KHsv3t8eVhPpaoGHqG7HG5I8ODAoOYEHupKXbthJXE8dOY2S+hQGGarxGq8m1aLB8jNhzgC8pWq3kiy5DP/f/09sc5E9cdOpdemndR9lzNIIuUIlLLNDiBu1oZSXmDNg1Vsotjnm+EL+ihgawXIVAiKObC4Gm0/9SQHLOBB7FfuO5qhlaZubmUSdvsyDtXCBDAeM/5ym0ckS52egX8kWsDk Content-Type: multipart/alternative; boundary="_000_MN2PR21MB13923DBD9C353C2663B13132911F2MN2PR21MB1392namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR21MB1392.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99631a23-43c4-46e4-25e3-08dd341baeb4 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2025 21:46:05.6151 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7UhEK4sSrLnSfD3Ota7G8SanOeHofAygVlcLY8c5rleuUq/vzsD5r934PKZNBNvWBZgkpD9xBtta00xagT79kg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR21MB3688 X-Spam-Status: No, score=-10.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FORGED_SPF_HELO, GIT_PATCH_0, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 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.30 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces~patchwork=sourceware.org@gcc.gnu.org |
| Series |
Fix setting of call graph node AutoFDO count [PR116743]
|
|
Checks
| Context | Check | Description |
|---|---|---|
| linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 | fail | Patch failed to apply |
| linaro-tcwg-bot/tcwg_gcc_build--master-arm | fail | Patch failed to apply |
Commit Message
Eugene Rozenfeld
Jan. 13, 2025, 9:46 p.m. UTC
We are initializing both the call graph node count and
the entry block count of the function with the head_count value
from the profile.
Count propagation algorithm may refine the entry block count
and we may end up with a case where the call graph node count
is set to 0 but the entry block count is non-zero. That becomes
a problem because we have this code in execute_fixup_cfg:
profile_count num = node->count;
profile_count den = ENTRY_BLOCK_PTR_FOR_FN (cfun)->count;
bool scale = num.initialized_p () && !(num == den);
Here if num is 0 but den is not 0, scale becomes true and we
lose the counts in
if (scale)
bb->count = bb->count.apply_scale (num, den);
This is what happened the issue reported in PR116743
(a 10% regression in MySQL HAMMERDB tests).
3d9e6767939e9658260e2506e81ec32b37cba041 made an improvement in
AutoFDO count propagation, which caused the mismatch between
the call graph node count (zero) and the entry block count (non-zero)
and subsequent loss of counts as described above.
The fix is to update the call graph node count once we've done count propagation.
Tested on x86_64-pc-linux-gnu.
gcc/ChangeLog:
PR gcov-profile/116743
* auto-profile.c (afdo_annotate_cfg): Fix mismatch between the call graph node count
and the entry block count.
---
gcc/auto-profile.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
/* Calculate, propagate count and probability information on CFG. */
afdo_calculate_branch_prob (&annotated_bb);
}
+ cgraph_node::get(current_function_decl)->count
+ = ENTRY_BLOCK_PTR_FOR_FN(cfun)->count;
update_max_bb_count ();
profile_status_for_fn (cfun) = PROFILE_READ;
if (flag_value_profile_transformations)
--
2.34.1
Comments
On Mon, Jan 13, 2025 at 10:47 PM Eugene Rozenfeld <Eugene.Rozenfeld@microsoft.com> wrote: > > We are initializing both the call graph node count and > > the entry block count of the function with the head_count value > > from the profile. > > > > Count propagation algorithm may refine the entry block count > > and we may end up with a case where the call graph node count > > is set to 0 but the entry block count is non-zero. That becomes > > a problem because we have this code in execute_fixup_cfg: > > > > profile_count num = node->count; > > profile_count den = ENTRY_BLOCK_PTR_FOR_FN (cfun)->count; > > bool scale = num.initialized_p () && !(num == den); > > > > Here if num is 0 but den is not 0, scale becomes true and we > > lose the counts in > > > > if (scale) > > bb->count = bb->count.apply_scale (num, den); > > > > This is what happened the issue reported in PR116743 > > (a 10% regression in MySQL HAMMERDB tests). > > 3d9e6767939e9658260e2506e81ec32b37cba041 made an improvement in > > AutoFDO count propagation, which caused the mismatch between > > the call graph node count (zero) and the entry block count (non-zero) > > and subsequent loss of counts as described above. > > > > The fix is to update the call graph node count once we've done count propagation. > > > > Tested on x86_64-pc-linux-gnu. OK. Thanks, Richard. > > > gcc/ChangeLog: > > PR gcov-profile/116743 > > * auto-profile.c (afdo_annotate_cfg): Fix mismatch between the call graph node count > > and the entry block count. > > --- > > gcc/auto-profile.cc | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/gcc/auto-profile.cc b/gcc/auto-profile.cc > > index 5d0e8afb9a1..aa4d1634f01 100644 > > --- a/gcc/auto-profile.cc > > +++ b/gcc/auto-profile.cc > > @@ -1538,8 +1538,6 @@ afdo_annotate_cfg (const stmt_set &promoted_stmts) > > if (s == NULL) > > return; > > - cgraph_node::get (current_function_decl)->count > > - = profile_count::from_gcov_type (s->head_count ()).afdo (); > > ENTRY_BLOCK_PTR_FOR_FN (cfun)->count > > = profile_count::from_gcov_type (s->head_count ()).afdo (); > > EXIT_BLOCK_PTR_FOR_FN (cfun)->count = profile_count::zero ().afdo (); > > @@ -1578,6 +1576,8 @@ afdo_annotate_cfg (const stmt_set &promoted_stmts) > > /* Calculate, propagate count and probability information on CFG. */ > > afdo_calculate_branch_prob (&annotated_bb); > > } > > + cgraph_node::get(current_function_decl)->count > > + = ENTRY_BLOCK_PTR_FOR_FN(cfun)->count; > > update_max_bb_count (); > > profile_status_for_fn (cfun) = PROFILE_READ; > > if (flag_value_profile_transformations) > > -- > > 2.34.1 > >
I committed the patch to trunk. Is it ok to backport to gcc-12, gcc-13, and gcc-14? -----Original Message----- From: Richard Biener <richard.guenther@gmail.com> Sent: Monday, January 13, 2025 11:22 PM To: Eugene Rozenfeld <Eugene.Rozenfeld@microsoft.com> Cc: GCC-Patches-ML <gcc-patches@gcc.gnu.org>; Jan Hubicka <hubicka@ucw.cz>; rvmallad@amazon.com Subject: [EXTERNAL] Re: [PATCH] Fix setting of call graph node AutoFDO count [PR116743] On Mon, Jan 13, 2025 at 10:47 PM Eugene Rozenfeld <Eugene.Rozenfeld@microsoft.com> wrote: > > We are initializing both the call graph node count and > > the entry block count of the function with the head_count value > > from the profile. > > > > Count propagation algorithm may refine the entry block count > > and we may end up with a case where the call graph node count > > is set to 0 but the entry block count is non-zero. That becomes > > a problem because we have this code in execute_fixup_cfg: > > > > profile_count num = node->count; > > profile_count den = ENTRY_BLOCK_PTR_FOR_FN (cfun)->count; > > bool scale = num.initialized_p () && !(num == den); > > > > Here if num is 0 but den is not 0, scale becomes true and we > > lose the counts in > > > > if (scale) > > bb->count = bb->count.apply_scale (num, den); > > > > This is what happened the issue reported in PR116743 > > (a 10% regression in MySQL HAMMERDB tests). > > 3d9e6767939e9658260e2506e81ec32b37cba041 made an improvement in > > AutoFDO count propagation, which caused the mismatch between > > the call graph node count (zero) and the entry block count (non-zero) > > and subsequent loss of counts as described above. > > > > The fix is to update the call graph node count once we've done count propagation. > > > > Tested on x86_64-pc-linux-gnu. OK. Thanks, Richard. > > > gcc/ChangeLog: > > PR gcov-profile/116743 > > * auto-profile.c (afdo_annotate_cfg): Fix mismatch > between the call graph node count > > and the entry block count. > > --- > > gcc/auto-profile.cc | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/gcc/auto-profile.cc b/gcc/auto-profile.cc > > index 5d0e8afb9a1..aa4d1634f01 100644 > > --- a/gcc/auto-profile.cc > > +++ b/gcc/auto-profile.cc > > @@ -1538,8 +1538,6 @@ afdo_annotate_cfg (const stmt_set > &promoted_stmts) > > if (s == NULL) > > return; > > - cgraph_node::get (current_function_decl)->count > > - = profile_count::from_gcov_type (s->head_count ()).afdo (); > > ENTRY_BLOCK_PTR_FOR_FN (cfun)->count > > = profile_count::from_gcov_type (s->head_count ()).afdo (); > > EXIT_BLOCK_PTR_FOR_FN (cfun)->count = profile_count::zero ().afdo > (); > > @@ -1578,6 +1576,8 @@ afdo_annotate_cfg (const stmt_set > &promoted_stmts) > > /* Calculate, propagate count and probability information on > CFG. */ > > afdo_calculate_branch_prob (&annotated_bb); > > } > > + cgraph_node::get(current_function_decl)->count > > + = ENTRY_BLOCK_PTR_FOR_FN(cfun)->count; > > update_max_bb_count (); > > profile_status_for_fn (cfun) = PROFILE_READ; > > if (flag_value_profile_transformations) > > -- > > 2.34.1 > >
On Thu, Jan 16, 2025 at 3:17 AM Eugene Rozenfeld <Eugene.Rozenfeld@microsoft.com> wrote: > > I committed the patch to trunk. Is it ok to backport to gcc-12, gcc-13, and gcc-14? Yes. > -----Original Message----- > From: Richard Biener <richard.guenther@gmail.com> > Sent: Monday, January 13, 2025 11:22 PM > To: Eugene Rozenfeld <Eugene.Rozenfeld@microsoft.com> > Cc: GCC-Patches-ML <gcc-patches@gcc.gnu.org>; Jan Hubicka <hubicka@ucw.cz>; rvmallad@amazon.com > Subject: [EXTERNAL] Re: [PATCH] Fix setting of call graph node AutoFDO count [PR116743] > > On Mon, Jan 13, 2025 at 10:47 PM Eugene Rozenfeld <Eugene.Rozenfeld@microsoft.com> wrote: > > > > We are initializing both the call graph node count and > > > > the entry block count of the function with the head_count value > > > > from the profile. > > > > > > > > Count propagation algorithm may refine the entry block count > > > > and we may end up with a case where the call graph node count > > > > is set to 0 but the entry block count is non-zero. That becomes > > > > a problem because we have this code in execute_fixup_cfg: > > > > > > > > profile_count num = node->count; > > > > profile_count den = ENTRY_BLOCK_PTR_FOR_FN (cfun)->count; > > > > bool scale = num.initialized_p () && !(num == den); > > > > > > > > Here if num is 0 but den is not 0, scale becomes true and we > > > > lose the counts in > > > > > > > > if (scale) > > > > bb->count = bb->count.apply_scale (num, den); > > > > > > > > This is what happened the issue reported in PR116743 > > > > (a 10% regression in MySQL HAMMERDB tests). > > > > 3d9e6767939e9658260e2506e81ec32b37cba041 made an improvement in > > > > AutoFDO count propagation, which caused the mismatch between > > > > the call graph node count (zero) and the entry block count (non-zero) > > > > and subsequent loss of counts as described above. > > > > > > > > The fix is to update the call graph node count once we've done count propagation. > > > > > > > > Tested on x86_64-pc-linux-gnu. > > OK. > > Thanks, > Richard. > > > > > > > gcc/ChangeLog: > > > > PR gcov-profile/116743 > > > > * auto-profile.c (afdo_annotate_cfg): Fix mismatch > > between the call graph node count > > > > and the entry block count. > > > > --- > > > > gcc/auto-profile.cc | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/gcc/auto-profile.cc b/gcc/auto-profile.cc > > > > index 5d0e8afb9a1..aa4d1634f01 100644 > > > > --- a/gcc/auto-profile.cc > > > > +++ b/gcc/auto-profile.cc > > > > @@ -1538,8 +1538,6 @@ afdo_annotate_cfg (const stmt_set > > &promoted_stmts) > > > > if (s == NULL) > > > > return; > > > > - cgraph_node::get (current_function_decl)->count > > > > - = profile_count::from_gcov_type (s->head_count ()).afdo (); > > > > ENTRY_BLOCK_PTR_FOR_FN (cfun)->count > > > > = profile_count::from_gcov_type (s->head_count ()).afdo (); > > > > EXIT_BLOCK_PTR_FOR_FN (cfun)->count = profile_count::zero ().afdo > > (); > > > > @@ -1578,6 +1576,8 @@ afdo_annotate_cfg (const stmt_set > > &promoted_stmts) > > > > /* Calculate, propagate count and probability information on > > CFG. */ > > > > afdo_calculate_branch_prob (&annotated_bb); > > > > } > > > > + cgraph_node::get(current_function_decl)->count > > > > + = ENTRY_BLOCK_PTR_FOR_FN(cfun)->count; > > > > update_max_bb_count (); > > > > profile_status_for_fn (cfun) = PROFILE_READ; > > > > if (flag_value_profile_transformations) > > > > -- > > > > 2.34.1 > > > >
diff --git a/gcc/auto-profile.cc b/gcc/auto-profile.cc index 5d0e8afb9a1..aa4d1634f01 100644 --- a/gcc/auto-profile.cc +++ b/gcc/auto-profile.cc @@ -1538,8 +1538,6 @@ afdo_annotate_cfg (const stmt_set &promoted_stmts) if (s == NULL) return; - cgraph_node::get (current_function_decl)->count - = profile_count::from_gcov_type (s->head_count ()).afdo (); ENTRY_BLOCK_PTR_FOR_FN (cfun)->count = profile_count::from_gcov_type (s->head_count ()).afdo (); EXIT_BLOCK_PTR_FOR_FN (cfun)->count = profile_count::zero ().afdo (); @@ -1578,6 +1576,8 @@ afdo_annotate_cfg (const stmt_set &promoted_stmts)