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 1C7EA3870924 for ; Fri, 17 Nov 2023 09:04:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1C7EA3870924 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1C7EA3870924 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700211856; cv=none; b=EB8YCSbtnf8oiwi0uVITjJAefjMrMbL3lcSdPIrwKZKBPGh64FBq6fufRVtooYuYBxS1pDrbiRnPTB+qWgJ31TX/rEwpUi5xj3XLNSBZ2+EootVngXy4OQf43q+fDi7ATTHDciv1veWT7rjavEnjU0Kd77Ua6gv/W4M3NF288jY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700211856; c=relaxed/simple; bh=GT8FVdE/xV4AnhGSntx77QiUKaPW6AwSuaugv7wFRuk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:From:Subject:To; b=DAp12FWqswJLQELVaSdXD9xLXUYAdpDXZHxA6wDCDamAZabNOteuA/eJSU0nEvkdiwbiMRDB1SuS0aflUy+NU+sjU63NnkUBFLZDQl4n0PEVgoc7Ja/bn53CeixoL8/UFDy/4fcGZDTzJZiDhaBHozpQVXFHH3et23+ve+a12Dc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353727.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3AH92E2T016969; Fri, 17 Nov 2023 09:04:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : from : subject : references : to : cc : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=/sMJfn/TotO5/PeDY5KNAgaltEFGN5tv+ZI94ToUeRM=; b=rki5WwlUlKpeODXUYdaiT9+CTaQIhSx+BAlZ77jqgUdB/Tg3rqw6M3A3YB4o9osbIBdX 6evQNDi2+8Tv1uN+ZE2L0aFniqnLgm8c+GI9h/Q5a739WT62TJ1ib9YLsbMbwsPP/LBo PGcH23Zs/Ato5Mf6Q9N+o3z7zf3zCIBZWZW4vREROzH6c890ZCWXckn9d3lkS7RM8O/d WC9oL8JXKbIvkZTMkFT+y1quVAzhJzJ0ROIeui0TBV1uVW+iR17rRIsQUg6O4RkGvjhd Ogz0XxzNozO8qnQlnN6lj7Df3C+AbHWkUDgWnHqsZ6Q7Pz/qwxmxX/Molue4yaDZmc+Y kw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ue56gr3rt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Nov 2023 09:04:06 +0000 Received: from m0353727.ppops.net (m0353727.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3AH92dcj019189; Fri, 17 Nov 2023 09:04:06 GMT Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ue56gr3nx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Nov 2023 09:04:05 +0000 Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3AH8mrGw032693; Fri, 17 Nov 2023 09:04:04 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 3uakxtd2kf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Nov 2023 09:04:04 +0000 Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3AH941H67995952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 17 Nov 2023 09:04:01 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 30EDB2004E; Fri, 17 Nov 2023 09:04:01 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7A7D720043; Fri, 17 Nov 2023 09:03:55 +0000 (GMT) Received: from [9.177.17.59] (unknown [9.177.17.59]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTP; Fri, 17 Nov 2023 09:03:55 +0000 (GMT) Message-ID: <9874e072-747a-39e9-da5e-d88f77b275aa@linux.ibm.com> Date: Fri, 17 Nov 2023 17:03:53 +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 From: "Kewen.Lin" Subject: Re: PING^1 [PATCH v3] sched: Change no_real_insns_p to no_real_nondebug_insns_p [PR108273] References: <85b4098e-a72f-d013-ff17-8097971f71ba@linux.ibm.com> <09FEFDAE-698B-4B06-A896-8088B9B31539@linaro.org> <4675c26c-f230-b6d6-27c5-bc9f74736e38@linux.ibm.com> <41a4d065-c4b6-4a67-adf0-e84e942616c7@gmail.com> <93ce3468-a1ee-e77c-cbeb-a8c67a303bf9@ispras.ru> <7eb725d9-de7c-87ba-5ebd-f2e1485c5854@ispras.ru> <475af219-f250-a0f4-78b0-998f96fb24aa@linux.ibm.com> Content-Language: en-US To: Alexander Monakov Cc: Richard Biener , Jeff Law , Maxim Kuvyrkov , GCC Patches , Richard Sandiford , Jeff Law , Vladimir Makarov , zhroma@ispras.ru, Andrey Belevantsev , Segher Boessenkool , Peter Bergner , Michael Meissner , Alexandre Oliva In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: wW94NkzHQQ1o8VY7eZN1bk6MSO-P-05c X-Proofpoint-ORIG-GUID: 5O72nCP864tLcQlKJtOmBP_XUlft6ZqQ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-17_06,2023-11-16_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0 clxscore=1015 spamscore=0 suspectscore=0 mlxscore=0 phishscore=0 malwarescore=0 lowpriorityscore=0 priorityscore=1501 mlxlogscore=889 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311170066 X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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 List-Id: on 2023/11/15 17:43, Alexander Monakov wrote: > > On Wed, 15 Nov 2023, Kewen.Lin wrote: > >>>> And I suppose it would be OK to do that. Empty BBs are usually removed by >>>> CFG cleanup so the situation should only happen in rare corner cases where >>>> the fix would be to actually run CFG cleanup ... >>> >>> Yeah, sel-sched invokes 'cfg_cleanup (0)' up front, and I suppose that >>> may be a preferable compromise for sched-rgn as well. >> >> Inspired by this discussion, I tested the attached patch 1 which is to run >> cleanup_cfg (0) first in haifa_sched_init, it's bootstrapped and >> regress-tested on x86_64-redhat-linux and powerpc64{,le}-linux-gnu. > > I don't think you can run cleanup_cfg after sched_init. I would suggest > to put it early in schedule_insns. Thanks for the suggestion, I placed it at the beginning of haifa_sched_init instead, since schedule_insns invokes haifa_sched_init, although the calls rgn_setup_common_sched_info and rgn_setup_sched_infos are executed ahead but they are all "setup" functions, shouldn't affect or be affected by this placement. > >> Then I assumed some of the current uses of no_real_insns_p won't encounter >> empty blocks any more, so made a patch 2 with some explicit assertions, but >> unfortunately I got ICEs during bootstrapping happens in function >> compute_priorities. I'm going to investigate it further and post more >> findings, but just heads-up to ensure if this is on the right track. > > I suspect this may be caused by invoking cleanup_cfg too late. By looking into some failures, I found that although cleanup_cfg is executed there would be still some empty blocks left, by analyzing a few failures there are at least such cases: 1. empty function body 2. block holding a label for return. 3. block without any successor. 4. block which becomes empty after scheduling some other block. 5. block which looks mergeable with its always successor but left. ... For 1,2, there is one single successor EXIT block, I think they don't affect state transition, for 3, it's the same. For 4, it depends on if we can have the assumption this kind of empty block doesn't have the chance to have debug insn (like associated debug insn should be moved along), I'm not sure. For 5, a reduced test case is: #include namespace std { template <> basic_istream & basic_istream::getline (char_type *, streamsize, char_type) __try { __streambuf_type *a = rdbuf (); a->sgetc (); while (traits_type::eq_int_type) ; } __catch (...) {} } // namespace std slim RTL: 1: NOTE_INSN_DELETED 7: NOTE_INSN_BASIC_BLOCK 2 ... 15: r137:CCUNS=cmp(r135:DI,r136:DI) REG_DEAD r136:DI REG_DEAD r135:DI 16: pc={(ltu(r137:CCUNS,0))?L24:pc} REG_DEAD r137:CCUNS REG_BR_PROB 966367644 17: NOTE_INSN_BASIC_BLOCK 3 18: r138:DI=[r122:DI] 19: r139:DI=[r138:DI+0x48] REG_DEAD r138:DI 20: %3:DI=r122:DI REG_DEAD r122:DI 21: %12:DI=r139:DI 22: ctr:DI=r139:DI REG_DEAD r139:DI 23: %3:DI=call [ctr:DI] argc:0 REG_DEAD ctr:DI REG_DEAD %12:DI REG_UNUSED %3:DI REG_EH_REGION 0x1 REG_CALL_DECL (nil) 24: L24: 25: NOTE_INSN_BASIC_BLOCK 4 51: L51: 48: NOTE_INSN_BASIC_BLOCK 5 47: NOTE_INSN_DELETED 52: pc=L51 53: barrier 39: L39: 41: NOTE_INSN_BASIC_BLOCK 6 32: %3:DI=call [`__cxa_begin_catch'] argc:0 REG_UNUSED %3:DI REG_CALL_DECL `__cxa_begin_catch' REG_EH_REGION 0 33: call [`__cxa_end_catch'] argc:0 REG_CALL_DECL `__cxa_end_catch' 34: barrier ;; basic block 4, loop depth 0, count 10631108 (estimated locally, freq 1.0000), maybe hot ;; prev block 3, next block 5, flags: (REACHABLE, RTL) ;; pred: 3 [always] count:1063111 (estimated locally, freq 0.1000) (FALLTHRU) ;; 2 [90.0% (guessed)] count:9567997 (estimated locally, freq 0.9000) ;; succ: 5 [always] count:10631108 (estimated locally, freq 1.0000) (FALLTHRU) ;; basic block 5, loop depth 0, count 1073741824 (estimated locally, freq 101.0000), maybe hot ;; prev block 4, next block 6, flags: (REACHABLE, RTL, MODIFIED) ;; pred: 4 [always] count:10631108 (estimated locally, freq 1.0000) (FALLTHRU) ;; 5 [always] count:1073741824 (estimated locally, freq 101.0000) ;; succ: 5 [always] count:1073741824 (estimated locally, freq 101.0000) It looks bb 4 can be merged with bb 5, a miss-opt? There can be some other cases similar to this, either it's miss-opt or not, it seems to affect our assumption. With the limited findings above so far, I wonder if we still want to go with this direction that running cleanup_cfg first and make the assumption that there is no such empty block which can cause debug and non-debug state inconsistency? IMHO it seems risky to make it. Thoughts? BR, Kewen