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 10AEE3857366 for ; Wed, 27 Jul 2022 14:10:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 10AEE3857366 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26RDfrRU019309 for ; Wed, 27 Jul 2022 14:10:57 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hk6fm18bt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 27 Jul 2022 14:10:56 +0000 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 26RDlsgA017835 for ; Wed, 27 Jul 2022 14:10:56 GMT Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hk6fm18b6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Jul 2022 14:10:56 +0000 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 26RE7Xfk017366; Wed, 27 Jul 2022 14:10:55 GMT Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by ppma04dal.us.ibm.com with ESMTP id 3hg989yvm3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Jul 2022 14:10:55 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 26REAsxt36438526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Jul 2022 14:10:54 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8B08278060; Wed, 27 Jul 2022 14:10:54 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A8A817805C; Wed, 27 Jul 2022 14:10:53 +0000 (GMT) Received: from [9.43.2.130] (unknown [9.43.2.130]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 27 Jul 2022 14:10:53 +0000 (GMT) Message-ID: <74f7c33b-7347-d9db-6d5f-568a6c5c4bc4@linux.vnet.ibm.com> Date: Wed, 27 Jul 2022 19:40:51 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [RFC] Analysis of PR105586 and possible approaches to fix issue Content-Language: en-US To: Richard Biener Cc: GCC Development References: From: Surya Kumari Jangala In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: lVIL4qyL4DpVS9i5mSGWcbHWsf37AnPD X-Proofpoint-ORIG-GUID: 7CyOm8oXGK6CuDk3pp9DtKdqzcDuAxkq 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-27_05,2022-07-27_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 priorityscore=1501 mlxlogscore=999 adultscore=0 phishscore=0 malwarescore=0 spamscore=0 suspectscore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207270056 X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, SPAM_BODY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2022 14:10:59 -0000 Hi Richard, On 27/07/22 12:28 pm, Richard Biener wrote: > On Tue, Jul 26, 2022 at 8:55 PM Surya Kumari Jangala via Gcc > wrote: >> To fix the issue of insns being assigned different cycles, there are two possible solutions: >> >> 1. Modify no_real_insns_p() to treat a DEBUG insn as a non-real insn (similar to NOTE and LABEL). With this change, bb 3 will not be scheduled in the debug mode (as it contains only NOTE and DEBUG insns). If scheduling is skipped, then bb 3’s state is not copied to bb 4 and the initial dfa state of bb 4 will be same in both debug and non-debug modes >> 2. Copy dfa state of a basic block to it’s fall-thru block only if the basic block contains ‘real’ insns (ie, it should contain at least one insn which is not a LABEL, NOTE or DEBUG). This will prevent copying of dfa state from bb 3 to bb 4 in debug mode. > > Do you know why the DFA state is not always copied to the fallthru > destination and then copied further even if the block does not contain I am not sure why the DFA state is not always copied to the fallthru destination. It is not very apparent from the code. > any (real) insns? It somewhat sounds like premature optimization > breaking things here... > Now that you mention it, yes it does seem suboptimal that the DFA state is not always copied. I don’t see any reason why the DFA state shouldn’t be always copied. And I think this is the fix for this bug. '-g' mode is behaving correctly, it is the non-debug mode which is incorrect. Thanks, Surya