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 55FDF3858D1E for ; Fri, 10 Nov 2023 11:25:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 55FDF3858D1E 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 55FDF3858D1E 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=1699615529; cv=none; b=uj6j1iLd1SyAq9p2jDYJFdhkiwgo9Zn6sWWdebe8JsG/ID6w9etD3/er9KoAZMk2giXCFElneJuBU/8VRbzBXPJyluapIt2ysHuA1ty7VoiCa8g7Zu1SbkGbfL9s8YOvJC6uomWvzULA4uYzKt+V+Ytps+CucpifZaTmXQ8ESDs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699615529; c=relaxed/simple; bh=j5DQbMBhF/QK7/TPtiP7XAYTPTKRgPjCwkEzTTD6R9g=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=TKVMnfSG+yPMe60clgCdkDTfn+Oi+1MUEqldKNl+t9Bkwl6CteWU+ktY8yMqplc4xRsPuvtKcC2JmqW9LT1EzxB59oBauDKiwqNyLz6c9MLsy4I+WWbxpykIAk7a9gukAy26U6v7BCa4l3VH6PsfYoZCqYGjSYI28gVC2j4DKb0= 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 E37C140F1DF0; Fri, 10 Nov 2023 11:25:24 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru E37C140F1DF0 Date: Fri, 10 Nov 2023 14:25:24 +0300 (MSK) From: Alexander Monakov To: Jeff Law cc: "Kewen.Lin" , Maxim Kuvyrkov , GCC Patches , Richard Guenther , Richard Sandiford , Jeff Law , Vladimir Makarov , zhroma@ispras.ru, Andrey Belevantsev , Segher Boessenkool , Peter Bergner , Michael Meissner , Alexandre Oliva Subject: Re: PING^1 [PATCH v3] sched: Change no_real_insns_p to no_real_nondebug_insns_p [PR108273] In-Reply-To: <41a4d065-c4b6-4a67-adf0-e84e942616c7@gmail.com> Message-ID: <93ce3468-a1ee-e77c-cbeb-a8c67a303bf9@ispras.ru> 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> 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, Jeff Law wrote: > > 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? > It sounds reasonable, but only if doing so doesn't add significant > implementation complexity. ie, the gains from doing less work here are likely > to be very marginal, so I'm more interested in clean, easy to maintain code. I'm afraid ignoring debug-only BBs goes contrary to overall var-tracking design: DEBUG_INSNs participate in dependency graph so that schedulers can remove or mutate them as needed when moving real insns across them. Cc'ing Alexandre Oliva who can correct me on that if necessary. Alexander