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 509703858D39 for ; Fri, 1 Jul 2022 09:42:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 509703858D39 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 2619KB46007832; Fri, 1 Jul 2022 09:42:17 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3h1x710ju0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Jul 2022 09:42:17 +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 2619L5vA010322; Fri, 1 Jul 2022 09:42:17 GMT Received: from ppma04fra.de.ibm.com (6a.4a.5195.ip4.static.sl-reverse.com [149.81.74.106]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3h1x710jsv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Jul 2022 09:42:16 +0000 Received: from pps.filterd (ppma04fra.de.ibm.com [127.0.0.1]) by ppma04fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2619PDdM032208; Fri, 1 Jul 2022 09:42:15 GMT Received: from b06avi18626390.portsmouth.uk.ibm.com (b06avi18626390.portsmouth.uk.ibm.com [9.149.26.192]) by ppma04fra.de.ibm.com with ESMTP id 3gwt0973ea-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Jul 2022 09:42:15 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2619f7Qs20447560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Jul 2022 09:41:07 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B872FA405B; Fri, 1 Jul 2022 09:42:12 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D7C15A405C; Fri, 1 Jul 2022 09:42:10 +0000 (GMT) Received: from [9.200.41.46] (unknown [9.200.41.46]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 1 Jul 2022 09:42:10 +0000 (GMT) Message-ID: Date: Fri, 1 Jul 2022 17:42:09 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: PING^1 [PATCH] inline: Rebuild target option node for caller [PR105459] Content-Language: en-US To: Richard Biener Cc: GCC Patches , Jakub Jelinek , Jan Hubicka , =?UTF-8?Q?Martin_Li=c5=a1ka?= References: <75d4b8f9-5ed2-de4c-d606-510a66714c9a@linux.ibm.com> <05835d48-50e9-be2c-2b60-1b42e9c6e5d6@linux.ibm.com> From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: I4r_pKzD5UNFQK3ZXyEvUv9Dhy_WmzHK X-Proofpoint-ORIG-GUID: mOfaZPPIz1we7IjbJc3yZ0IyYZJyT2Lt Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 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-01_05,2022-06-28_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 bulkscore=0 clxscore=1011 suspectscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2207010034 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, 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: Fri, 01 Jul 2022 09:42:21 -0000 Hi Richi, Thanks for the insightful comments! on 2022/7/1 16:40, Richard Biener wrote: > On Thu, Jun 23, 2022 at 4:03 AM Kewen.Lin wrote: >> >> Hi, >> >> Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596212.html >> >> BR, >> Kewen >> >> on 2022/6/6 14:20, Kewen.Lin via Gcc-patches wrote: >>> Hi, >>> >>> PR105459 exposes one issue in inline_call handling that when it >>> decides to copy FP flags from callee to caller and rebuild the >>> optimization node for caller fndecl, it's possible that the target >>> option node is also necessary to be rebuilt. Without updating >>> target option node early, it can make nodes share the same target >>> option node wrongly, later when we want to unshare it somewhere >>> (like in target hook) it can get unexpected results, like ICE on >>> uninitialized secondary member of target globals exposed in this PR. > > I think that > > /* Reload global optimization flags. */ > if (reload_optimization_node && DECL_STRUCT_FUNCTION (to->decl) == cfun) > set_cfun (cfun, true); > > is supposed to do that via ix86_set_current_function which will eventually > re-build the target optimization node exactly for this reason. > > But with LTO we arrive here during WPA time only and there cfun is NULL > (and so is DECL_STRUCT_FUNCTION (to->decl)), so the target doesn't > get the chance to fix things up here. > Yes, when I read this code, I was thinking if we can do some similar to get the hook to update target node, but as you pointed out, the cfun is NULL here. :( > Now, it should be fine to delay this fixup until we set the cfun at LTRANS > time but there we run into > > if (old_tree != new_tree) > { > cl_target_option_restore (&global_options, &global_options_set, > TREE_TARGET_OPTION (new_tree)); > ... > } > else if (flag_unsafe_math_optimizations > != TREE_TARGET_OPTION (new_tree)->x_ix86_unsafe_math_optimizations > || (flag_excess_precision > != TREE_TARGET_OPTION (new_tree)->x_ix86_excess_precision)) > { > ... FIXUP! ... > > and old_tree != new_tree disables the fixup. > > When we refactor the above to always consider the FP flag change (so apply it > lazily), then this fixes the testcase in the PR as well. Thus something like > the attached. Good idea! Previously following the code for reload_optimization_node, I thought it's good to update the target node information up to date at the same time, but your proposal with delaying fixup till LTRANS looks better, IIUC WPA passes won't care about this information out of date or not. > > Ideally this stuff would be refactored to a target hook that can work without > the set_cfun, also working towards merging the target and optimization node > since they have to be kept in sync ... > > I think your proposed patch makes another variant through the maze to > do something at WPA time but that makes it all even more complicated :/ > > Sorry for the delay btw. > No problem! Thanks again!! BR, Kewen