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 E99D63858D38 for ; Fri, 10 Nov 2023 01:57:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E99D63858D38 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 E99D63858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699581450; cv=none; b=soOOV09EmARWT5lESZYOMZkvfO01mnFgjyLQcoLCw7qCDjom7enwgGa24L0HMnbqNyCBnh4frImz7u5cxHdliO6RDFdHSQLVN+55RAtzDhWcu+OP4+NNzzEfrsDCydBAxb7jTHj7FEdRr3VWsEboLEk59ijX+gjf3mFtAh8oJyM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699581450; c=relaxed/simple; bh=eK+SyISWGS25hffPx/50rSCQyLaNnpgFUjJwgwRI2NM=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=Ff4i1YKlBS6sW4xnok5u0r+dLlXoeKDMUExzyYC+2Nwvw2a3/bv1iuc/Ce/vNlVVaWC/KEzOBhpO/WUWYIcyfh8tSDS5z8Q8qIelr4zDuC46Vl3F4DINkGeKtMf5UYEVt5Z0sGQYEw/JBM7VybCW0dy2skwqZrIp2s46je/NtSk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3AA1jAK7015244; Fri, 10 Nov 2023 01:57:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pp1; bh=RGHy2L9O+54i3HsxR9l0ZCp8EvM4MtfoZCocgkuixq4=; b=Amz/llyXxc7rRQfI7Vt1e0TRRMLAVkUEfWQsZTi4dQY7fG2+7UDBDJjCq5xcSwR0ndHE FahCQtb1tDJhY/fDLnvFK8NJySp+bwq0VGj1APZCqUeLUhrqWVgOD+N8cebWh4EnEp5v RlPiepyRU1Q9N4thmK3u4x6diIxLMnCtzjCsKXwM/vCM876r4F1y8rS51B8cvtf7DcP5 dXvQtn6rkNz5GZb7qPnnFarbPUl6oq1plyZmbavryYexeOyCkJRon2WzYmOcKolFLD08 BwErcPRF8VEklnvXYKxqoIW7toVGYYcf1jsRZ/x/hwW0ma7T3H/8RBJofumqR2Owiffe 4Q== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3u9b4hg89e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Nov 2023 01:57:25 +0000 Received: from m0356516.ppops.net (m0356516.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3AA1kE7P018147; Fri, 10 Nov 2023 01:57:24 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3u9b4hg893-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Nov 2023 01:57:24 +0000 Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3AA1WtDJ028363; Fri, 10 Nov 2023 01:57:23 GMT Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3u7w22qtvb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Nov 2023 01:57:23 +0000 Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com [10.20.54.104]) by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3AA1vKEP22151436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Nov 2023 01:57:20 GMT Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4E55F2004B; Fri, 10 Nov 2023 01:57:20 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AE65720040; Fri, 10 Nov 2023 01:57:15 +0000 (GMT) Received: from [9.177.22.139] (unknown [9.177.22.139]) by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTP; Fri, 10 Nov 2023 01:57:15 +0000 (GMT) Message-ID: <4675c26c-f230-b6d6-27c5-bc9f74736e38@linux.ibm.com> Date: Fri, 10 Nov 2023 09:57:13 +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 v3] sched: Change no_real_insns_p to no_real_nondebug_insns_p [PR108273] Content-Language: en-US To: Alexander Monakov , Maxim Kuvyrkov Cc: GCC Patches , Richard Guenther , Richard Sandiford , Jeff Law , Vladimir Makarov , zhroma@ispras.ru, Andrey Belevantsev , Segher Boessenkool , Peter Bergner , Michael Meissner References: <85b4098e-a72f-d013-ff17-8097971f71ba@linux.ibm.com> <09FEFDAE-698B-4B06-A896-8088B9B31539@linaro.org> From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: Yp9IJyOYO_04qsNhMDroq0ZxXGf573d4 X-Proofpoint-GUID: fmdejvexBWSLDkOKA6w-H19CmURPrgs5 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.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-09_17,2023-11-09_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 adultscore=0 malwarescore=0 mlxscore=0 phishscore=0 bulkscore=0 clxscore=1011 priorityscore=1501 impostorscore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311100015 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: Hi Maxim and Alexander, Thanks a lot for the review comments! on 2023/11/10 01:40, Alexander Monakov wrote: > > On Thu, 9 Nov 2023, Maxim Kuvyrkov wrote: > >> Hi Kewen, >> >> Below are my comments. I don't want to override Alexander's review, and if >> the patch looks good to him, it's fine to ignore my concerns. >> >> My main concern is that this adds a new entity -- forceful skipping of >> DEBUG_INSN-only basic blocks -- to the scheduler for a somewhat minor change >> in behavior. Unlike NOTEs and LABELs, DEBUG_INSNs are INSNS, and there is >> already quite a bit of logic in the scheduler to skip them _as part of normal >> operation_. Yeah, I noticed that the scheduler takes care of DEBUG_INSNs as normal operations. When I started to work on this issue, initially I wanted to try something similar to your idea #2, but when checking the APIs, I realized why not just skip the basic block with NOTEs and LABELs, DEBUG_INSNs as well. IMHO there is no value to try to schedule this kind of BB (to be scheduled range), skipping it can save some resource allocation (like block dependencies) and make it more efficient (not enter function schedule_block etc.), from this perspective it seems an enhancement. Does it sound reasonable to you? > > I agree with the concern. I hoped that solving the problem by skipping the BB > like the (bit-rotted) debug code needs to would be a minor surgery. As things > look now, it may be better to remove the non-working sched_block debug counter > entirely and implement a good solution for the problem at hand. OK, if debug counter sched_block is useless and can be removed, then the proposed new skipping becomes the only actual need for the artificial resolve_forw_deps. > >> >> Would you please consider 2 ideas below. >> >> #1: >> After a brief look, I'm guessing this part is causing the problem: >> haifa-sched.cc :schedule_block(): >> === [1] >> /* Loop until all the insns in BB are scheduled. */ >> while ((*current_sched_info->schedule_more_p) ()) >> { >> perform_replacements_new_cycle (); >> do >> { >> start_clock_var = clock_var; >> >> clock_var++; >> >> advance_one_cycle (); > > As I understand, we have spurious calls to advance_one_cycle on basic block > boundaries, which don't model the hardware (the CPU doesn't see BB boundaries) > and cause divergence when passing through a debug-only BB which would not be > present at all without -g. > > Since EBBs and regions may not have jump targets in the middle, advancing > a cycle on BB boundaries does not seem well motivated. Can we remove it? > > Can we teach haifa-sched to emit RTX NOTEs with hashes of DFA states on BB > boundaries with -fcompare-debug is enabled? It should make the problem > readily detectable by -fcompare-debug even when scheduling did not diverge. Good idea! It would be easy to detect the inconsistent issue with such note. BR, Kewen