From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id 7D4333858D38 for ; Thu, 9 Nov 2023 17:40:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7D4333858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7D4333858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=83.149.199.84 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699551621; cv=none; b=LarTuocGBtLn4MUCVf/pgNVcPqUcSStADITbd+b9EtwiyUVShrAkWseay5vyXKEgTHDubOAI1cnAgXorR4dYfVpBXYR5TRUW2kvR8Te/zYRWa9YGLonoJMhXqDAGM+JCYLd+OenRFy8NBCBus3A9qTkQdZMmPeOECp8LnnxJobQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699551621; c=relaxed/simple; bh=tLswuTbdw+hoGGjhIfM5FG4KZ2CQUN89ftmsIjzt+tY=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=cFsLdkQRAZDOXIqP5kWxTExhrcFE2wemBXjq38Lkw+CiteXrG2k1RO/iDT16hRIi7NraDRSx1wMNPR3cNsLjgGpUA+ZaSRSkDI7d7wOdCzT+EWbcgB1XQT5esDuWRv2FmVpYFXGAEpqu6k/7AxiZwAu6VYgO4XUnGAoLDgaahhk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.10.3.121] (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id 0AC2E40F1DC9; Thu, 9 Nov 2023 17:40:17 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 0AC2E40F1DC9 Date: Thu, 9 Nov 2023 20:40:16 +0300 (MSK) From: Alexander Monakov To: Maxim Kuvyrkov cc: "Kewen.Lin" , GCC Patches , Richard Guenther , Richard Sandiford , Jeff Law , Vladimir Makarov , zhroma@ispras.ru, Andrey Belevantsev , Segher Boessenkool , Peter Bergner , Michael Meissner Subject: Re: PING^1 [PATCH v3] sched: Change no_real_insns_p to no_real_nondebug_insns_p [PR108273] In-Reply-To: <09FEFDAE-698B-4B06-A896-8088B9B31539@linaro.org> Message-ID: References: <85b4098e-a72f-d013-ff17-8097971f71ba@linux.ibm.com> <09FEFDAE-698B-4B06-A896-8088B9B31539@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,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 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_. 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. > > 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. Alexander