From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id EB4FF3858438 for ; Wed, 28 Sep 2022 05:46:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EB4FF3858438 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 28S4BG8e000866; Wed, 28 Sep 2022 05:46:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=+78b0DlLr6CbUhWb3VRr94dKZrnF7dIBW6ZFk9Im5fc=; b=cJQhS+gJRRXeoGV3Fb0mLxRlbNKClomwJPwQ7jL1kBhCUndYh4hfxpLB1C0pa0pn48Wr ciFrgf3Mi207uak2ngpqBuXpcQD02BzcCRuo1Jn84WZ08evzNPYnvUjvsk1BHPPqlS8V EW2C+mu02rgg21roQ0NEmve2kRlJPowAc+JS6u6pdDUWpydzS/3P5Xk+Icqz54DDxg6W pS9uaRIx47k4X79bYvLbl2C7eiNk5spe5PsvOjeDO7wDozcaz3bRDRVOonb0/gfuVAZf CutsA13koDyOxFNUJHeUVoKeJVyRww8hpAgc3yeWnfEROlc5YL9dwLb5Nq1azZgz6B9D Jw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jved2aje5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Sep 2022 05:46:35 +0000 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 28S5eMKh036150; Wed, 28 Sep 2022 05:46:34 GMT Received: from ppma01fra.de.ibm.com (46.49.7a9f.ip4.static.sl-reverse.com [159.122.73.70]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3jved2ajdp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Sep 2022 05:46:34 +0000 Received: from pps.filterd (ppma01fra.de.ibm.com [127.0.0.1]) by ppma01fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 28S5ZMH3026151; Wed, 28 Sep 2022 05:46:33 GMT Received: from b06avi18878370.portsmouth.uk.ibm.com (b06avi18878370.portsmouth.uk.ibm.com [9.149.26.194]) by ppma01fra.de.ibm.com with ESMTP id 3jssh8ujb7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Sep 2022 05:46:32 +0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06avi18878370.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 28S5kwA734931102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 Sep 2022 05:46:58 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BD4F842045; Wed, 28 Sep 2022 05:46:30 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C23CA4203F; Wed, 28 Sep 2022 05:46:28 +0000 (GMT) Received: from [9.197.236.18] (unknown [9.197.236.18]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 28 Sep 2022 05:46:28 +0000 (GMT) Message-ID: <3de46b48-76a2-1f11-9dfc-1b7f702386d4@linux.ibm.com> Date: Wed, 28 Sep 2022 13:46:27 +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 To: Jan Hubicka Cc: Richard Sandiford , GCC Patches , Jan Hubicka , Segher Boessenkool , Richard Biener References: <23b4998b-bbe6-b052-d7f5-5304ee0f46a3@linux.ibm.com> <77f90ce9-8c36-e442-03b6-82d5450da2a1@linux.ibm.com> <0122f231-450a-1280-ba23-fb7127412aa9@linux.ibm.com> <5404908f-76d9-8898-3621-1f54064892fb@linux.ibm.com> From: "Kewen.Lin" In-Reply-To: <5404908f-76d9-8898-3621-1f54064892fb@linux.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: PS4kJQpuJjtXxwU5ymQHtx3-_eo5Wb6t X-Proofpoint-ORIG-GUID: Do2Qj4vo9y5vMYf_zknbTubeWOEUJhLp X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1 definitions=2022-09-28_02,2022-09-27_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 priorityscore=1501 impostorscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 adultscore=0 spamscore=0 malwarescore=0 lowpriorityscore=0 mlxscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2209280032 X-Spam-Status: No, score=-13.2 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 autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: on 2022/8/29 14:35, Kewen.Lin via Gcc-patches wrote: > on 2022/8/15 16:33, Kewen.Lin via Gcc-patches wrote: >> on 2022/7/11 11:42, Kewen.Lin wrote: >>> 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? >>> Hi Honza, Gentle ping^4 ... BR, Kewen