From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 37D2D3858400 for ; Mon, 11 Jul 2022 03:42:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 37D2D3858400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26B28NSn022912; Mon, 11 Jul 2022 03:42:19 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3h7ygdjphb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Jul 2022 03:42:19 +0000 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 26B3XT88029859; Mon, 11 Jul 2022 03:42:18 GMT Received: from ppma06fra.de.ibm.com (48.49.7a9f.ip4.static.sl-reverse.com [159.122.73.72]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3h7ygdjpgx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Jul 2022 03:42:18 +0000 Received: from pps.filterd (ppma06fra.de.ibm.com [127.0.0.1]) by ppma06fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 26B3LYaQ018191; Mon, 11 Jul 2022 03:42:16 GMT Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by ppma06fra.de.ibm.com with ESMTP id 3h70xhska4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Jul 2022 03:42:15 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 26B3gDcB23855398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Jul 2022 03:42:13 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9E9C7A4054; Mon, 11 Jul 2022 03:42:13 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B1775A405F; Mon, 11 Jul 2022 03:42:11 +0000 (GMT) Received: from [9.197.244.15] (unknown [9.197.244.15]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 11 Jul 2022 03:42:11 +0000 (GMT) Message-ID: Date: Mon, 11 Jul 2022 11:42:08 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH] predict: Adjust optimize_function_for_size_p [PR105818] Content-Language: en-US From: "Kewen.Lin" To: Jan Hubicka Cc: GCC Patches , Richard Sandiford , Segher Boessenkool , Richard Biener References: <23b4998b-bbe6-b052-d7f5-5304ee0f46a3@linux.ibm.com> <77f90ce9-8c36-e442-03b6-82d5450da2a1@linux.ibm.com> In-Reply-To: <77f90ce9-8c36-e442-03b6-82d5450da2a1@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: nFLV4tSqiEA0KTbxUVoWMgo8U_354q3i X-Proofpoint-ORIG-GUID: 0eIjClGSIDZKsaGy8WfO6xpjjG1jEtb4 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-07-10_18,2022-07-08_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxscore=0 clxscore=1015 impostorscore=0 suspectscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207110013 X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2022 03:42:25 -0000 on 2022/6/15 14:20, Kewen.Lin wrote: > Hi Honza, > > Thanks for the comments! Some replies are inlined below. > > on 2022/6/14 19:37, Jan Hubicka wrote: >>> Hi, >>> >>> Function optimize_function_for_size_p returns OPTIMIZE_SIZE_NO >>> if func->decl is not null but no cgraph node is available for it. >>> As PR105818 shows, this could give unexpected result. For the >>> case in PR105818, when parsing bar decl in function foo, the cfun >>> is a function structure for foo, for which there is none cgraph >>> node, so it returns OPTIMIZE_SIZE_NO. But it's incorrect since >>> the context is to optimize for size, the flag optimize_size is >>> true. >>> >>> The patch is to make optimize_function_for_size_p to check >>> optimize_size as what it does when func->decl is unavailable. >>> >>> One regression failure got exposed on aarch64-linux-gnu: >>> >>> PASS->FAIL: gcc.dg/guality/pr54693-2.c -Os \ >>> -DPREVENT_OPTIMIZATION line 21 x == 10 - i >>> >>> The difference comes from the macro LOGICAL_OP_NON_SHORT_CIRCUIT >>> used in function fold_range_test during c parsing, it uses >>> optimize_function_for_speed_p which is equal to the invertion >>> of optimize_function_for_size_p. At that time cfun->decl is valid >>> but no cgraph node for it, w/o this patch function >>> optimize_function_for_speed_p returns true eventually, while it >>> returns false with this patch. Since the command line option -Os >>> is specified, there is no reason to interpret it as "for speed". >>> I think this failure is expected and adjust the test case >>> accordingly. >>> >>> Is it ok for trunk? >>> >>> BR, >>> Kewen >>> ----- >>> >>> PR target/105818 >>> >>> gcc/ChangeLog: >>> >>> * predict.cc (optimize_function_for_size_p): Check optimize_size when >>> func->decl is valid but its cgraph node is unavailable. >>> >>> gcc/testsuite/ChangeLog: >>> >>> * gcc.target/powerpc/pr105818.c: New test. >>> * gcc.dg/guality/pr54693-2.c: Adjust for aarch64. >>> --- >>> gcc/predict.cc | 2 +- >>> gcc/testsuite/gcc.dg/guality/pr54693-2.c | 2 +- >>> gcc/testsuite/gcc.target/powerpc/pr105818.c | 9 +++++++++ >>> 3 files changed, 11 insertions(+), 2 deletions(-) >>> create mode 100644 gcc/testsuite/gcc.target/powerpc/pr105818.c >>> >>> diff --git a/gcc/predict.cc b/gcc/predict.cc >>> index 5734e4c8516..6c60a973236 100644 >>> --- a/gcc/predict.cc >>> +++ b/gcc/predict.cc >>> @@ -268,7 +268,7 @@ optimize_function_for_size_p (struct function *fun) >>> cgraph_node *n = cgraph_node::get (fun->decl); >>> if (n) >>> return n->optimize_for_size_p (); >>> - return OPTIMIZE_SIZE_NO; >>> + return optimize_size ? OPTIMIZE_SIZE_MAX : OPTIMIZE_SIZE_NO; >> >> We could also do (opt_for_fn (cfun->decl, optimize_size) that is >> probably better since one can change optimize_size with optimization >> attribute. > > Good point, agree! > >> However I think in most cases we check for optimize_size early I think >> we are doing something wrong, since at that time htere is no profile >> available. Why exactly PR105818 hits the flag change issue? > > For PR105818, the reason why the flag changs is that: > > Firstly, the inconsistent flag is OPTION_MASK_SAVE_TOC_INDIRECT bit > of rs6000_isa_flags_explicit, it's set as below: > > /* If we can shrink-wrap the TOC register save separately, then use > -msave-toc-indirect unless explicitly disabled. */ > if ((rs6000_isa_flags_explicit & OPTION_MASK_SAVE_TOC_INDIRECT) == 0 > && flag_shrink_wrap_separate > && optimize_function_for_speed_p (cfun)) > rs6000_isa_flags |= OPTION_MASK_SAVE_TOC_INDIRECT; > > Initially, rs6000 initialize target_option_default_node with > OPTION_MASK_SAVE_TOC_INDIRECT unset, at that time cfun is NULL > and optimize_size is true. > > Later, when c parser handling function foo, it builds target > option node as target_option_default_node in function > handle_optimize_attribute, it does global option saving and > verifying there as well, at that time the cfun is NULL, no > issue is found. And function store_parm_decls allocates > struct_function for foo then, cfun becomes function struct > for foo, when c parser continues to handle the decl bar in > foo, function handle_optimize_attribute works as before, > tries to restore the target options at the end, it calls > targetm.target_option.restore (rs6000_function_specific_restore) > which calls function rs6000_option_override_internal again, > at this time the cfun is not NULL while there is no cgraph > node for its decl, optimize_function_for_speed_p returns true > and gets the OPTION_MASK_SAVE_TOC_INDIRECT bit of flag > rs6000_isa_flags set unexpectedly. It becomes inconsistent > as the one saved previously. > > IMHO, both contexts of global and function decl foo here hold > optimize_size, function optimize_function_for_speed_p should > not return true anyway. > > btw, the aarch64 failed case also gets the unexpected > result for optimize_function_for_speed_p during c parsing > (fold_range_test <- ... <- c_parser_condition). > > IIUC, in parsing time we don't have the profile information > available. > Hi Honza, Does the above explanation sound reasonable to you? BR, Kewen