From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from server.nextmovesoftware.com (server.nextmovesoftware.com [162.254.253.69]) by sourceware.org (Postfix) with ESMTPS id AA479385829C for ; Mon, 11 Jul 2022 08:33:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AA479385829C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nextmovesoftware.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nextmovesoftware.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nextmovesoftware.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YjEuUcidTN86ZaqlbdwgO/voFOFRkG0en32OrJQ2dfk=; b=hijMbL2SuAc4hawMq7DlAhZjg2 /r9196N25yNcjLc8oJci2fahwBOrx89qjty+xaQwwQlSCHD7srXs/ItBpo+x3rnSueyv4N/8rJrDn 7ZDeg6lpwRsRUCubMLahLS4kxU0EkvDT0LYr33FK5Q16FHHpsxnO/bdVCZd66MIO39amjha2DPydt shVY0ow+RHpNuozFctjICSAvjgf+KLDgdL85VXEb7yB02hZc25irAfj6lRTGAZuKo6EvdsM0tmRMr RhNYMehzuIbJnFFLEX23Cz+ltq1yxxdUmVMyRqqgIhskkyPFdLWBs2FcCZXhgJSL11dNot1hz7lLy xG65Y0jw==; Received: from host86-130-134-60.range86-130.btcentralplus.com ([86.130.134.60]:62360 helo=Dell) by server.nextmovesoftware.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oAor9-0001Fq-Rf; Mon, 11 Jul 2022 04:33:28 -0400 From: "Roger Sayle" To: "'Richard Biener'" Cc: References: <00e601d89489$a5133740$ef39a5c0$@nextmovesoftware.com> In-Reply-To: Subject: RE: [PATCH] Move reload_completed and other rtl.h globals to crtl structure. Date: Mon, 11 Jul 2022 09:33:24 +0100 Message-ID: <020401d89500$e3f6ca90$abe45fb0$@nextmovesoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJ+Wq6Ez11XRTvRWOiFvVCF6V3E0AGuep8frB/I73A= Content-Language: en-gb X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.nextmovesoftware.com X-AntiAbuse: Original Domain - gcc.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nextmovesoftware.com X-Get-Message-Sender-Via: server.nextmovesoftware.com: authenticated_id: roger@nextmovesoftware.com X-Authenticated-Sender: server.nextmovesoftware.com: roger@nextmovesoftware.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2022 08:33:33 -0000 On 11 July 2022 08:20, Richard Biener wrote: > On Sun, 10 Jul 2022, Roger Sayle wrote: > > > This patch builds upon Richard Biener's suggestion of avoiding global > > variables to track state/identify which passes have already been run. > > In the early middle-end, the tree-ssa passes use the curr_properties > > field in cfun to track this. This patch uses a new rtl_pass_progress > > int field in crtl to do something similar. > > Why not simply add PROP_rtl_... and use the existing curr_properties for this? > RTL passes are also passes and this has the advantage you can add things like > reload_completed to the passes properties_set field hand have the flag setting > handled by the pass manager as it was intended? > Great question, and I did initially consider simply adding more RTL fields to curr_properties. My hesitation was from the comments/documentation that the curr_properties field is used by the pass manager as a way to track (and verify) the properties/invariants that are required, provided and destroyed by each pass. This semantically makes sense for properties such as accurate data flow, ssa form, cfg_layout, nonzero_bits etc, where hypothetically the pass manager can dynamically schedule a pass/analysis to ensure the next pass has the pre-requisite information it needs. This seems semantically slightly different from tracking time/progress, where we really want something more like DEBUG_COUNTER that simply provides the "tick-tock" of a pass clock. Alas, the "pass number", as used in the suffix of dump-files (where 302 currently means reload) isn't particularly useful as these change/evolve continually. Perhaps the most obvious indication of this (subtle) difference is the curr_properties field (PROP_rtl_split_insns) which tracks whether instructions have been split, where at a finer granularity rtl_pass_progress may wish to distinguish split1 (after combine before reload), split2 (after reload before peephole2) and split3 (after peephole2). It's conceptually not a simple property, whether all insns have been split or not, as in practice this is more subtle with backends choosing which instructions get split at which "times". There's also the concern that we've a large number of passes (currently 62 RTL passes), and only a finite number of bits (in curr_properties), so having two integers reduces the risk of running out of bits and needing to use a "wider" data structure. To be honest, I just didn't want to hijack curr_properties to abuse it for a use that didn't quite match the original intention, without checking with you and the other maintainers first. If the above reasoning isn't convincing, I can try spinning an alternate patch using curr_properties (but I'd expect even more churn as backend source files would now need to #include tree-passes.h and function.h to get reload_completed). And of course, a volunteer is welcome to contribute that re-refactoring after this one. I've no strong feelings either way. It was an almost arbitrary engineering decision (but hopefully the above explains the balance of my reasoning). Roger --