From patchwork Mon Oct 16 05:38:50 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sandra Loosemore X-Patchwork-Id: 826133 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-464233-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="vY4y9tJN"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3yFnFL3vqDz9sPk for ; Mon, 16 Oct 2017 16:39:14 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:cc:message-id:date:mime-version:content-type; q= dns; s=default; b=gR4UNKU2XXYAmbTdlagY0oaB10zTLZGbZm9SrE4WvMA8Cf 21wdLorlgj2J5vqcqTxPBuwPZG5PdoFcxStaLok5VsjuNIvu23veyxWPCQc5vvDi n/9aIKvAia/BQ0jmtg7ZkxhbyYwIgnp+t6MojCDsdCjzGCkeWTaRefWSBHZ6c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to :from:subject:cc:message-id:date:mime-version:content-type; s= default; bh=0qCcQ9jOWRCsPb2ERZMQ5gDlmNo=; b=vY4y9tJNQKRbIU/ABjQL mWC2mapAlVMl0Ueq4sadh3zepIzG+BQ1PTUmDqJyhcXFxpY4+T9EhkybMfI77Dwy Xrc0Ryl0nk6WnAxHeNmWOa7uwjAvT/DREdb4tqmT92oQxnPBCpOGgO12rhz86smn DhAKXpWgQ1Lga6jyiOBPFo0= Received: (qmail 50389 invoked by alias); 16 Oct 2017 05:39:03 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 50378 invoked by uid 89); 16 Oct 2017 05:39:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-10.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, SPF_PASS, URIBL_RED autolearn=ham version=3.3.2 spammy=wiring, plays, U*sandra, sk:sandra X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Oct 2017 05:39:00 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1e3y74-00022f-1j from Sandra_Loosemore@mentor.com ; Sun, 15 Oct 2017 22:38:54 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 15 Oct 2017 22:38:51 -0700 To: "gcc-patches@gcc.gnu.org" From: Sandra Loosemore Subject: [PATCH, RFC] Add a pass counter for "are we there yet" purposes CC: , Jeff Law , Jakub Jelinek Message-ID: <59E445EA.5030909@codesourcery.com> Date: Sun, 15 Oct 2017 23:38:50 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 X-ClientProxiedBy: svr-orw-mbx-02.mgc.mentorg.com (147.34.90.202) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) This patch is a first cut at solving the problem discussed in this thread https://gcc.gnu.org/ml/gcc/2017-10/msg00016.html where I have some nios2 backend patches in my queue that need a way of knowing whether the split1 pass has run yet. There seemed to be agreement that a general way to query the pass manager for this information would be useful. The approach I took here is to add a new counter field, so that I can do the test I want with opt_pass *split1_pass = g->get_passes ()->get_pass_split_all_insns (); if (current_pass->pass_number > split1_pass->pass_number) ... Well, mostly. :-P There are some gotchas. * TARGET_ASM_OUTPUT_MI_THUNK is called outside the pass manager (so current_pass is NULL) and on many targets this hook is implemented by setting reload_completed to 1, generating some RTL, and invoking some passes directly to emit code. * modulo-sched.c also plays tricks with setting reload_completed to pretend to be something it's not. * Possibly other places? E.g. I'm not familiar with how plugins work. For my purposes it's good enough to check reload_completed before the test in the code snippet above, but trying to determine whether a particular post-reload pass has run won't work. So this isn't as general as it ought to be, at least not until we get rid of the reload_completed hackery. Since this patch isn't useful without something that uses the pass counters, I tested it on nios2-linux-gnu with my not-yet-posted patch set, by wiring it up in parallel with my previously-implemented solution of adding a target-specific pass to set a flag, with various assertions to check for consistency. I also had some temporary debugging code in there at one point to print the pass numbers. WDYT? Is this the right direction? I'm somewhat worried that we're getting late in stage 1 and I'd really like to finish up my nios2 patches; so if getting this right looks like a tar pit, I think I should probably stick with my previous implementation for now. -Sandra Index: gcc/pass_manager.h =================================================================== --- gcc/pass_manager.h (revision 253327) +++ gcc/pass_manager.h (working copy) @@ -103,6 +103,7 @@ private: void set_pass_for_id (int id, opt_pass *pass); void register_dump_files (opt_pass *pass); void create_pass_tab () const; + void enumerate_passes () const; private: context *m_ctxt; Index: gcc/tree-pass.h =================================================================== --- gcc/tree-pass.h (revision 253327) +++ gcc/tree-pass.h (working copy) @@ -108,6 +108,11 @@ public: /* Static pass number, used as a fragment of the dump file name. */ int static_pass_number; + /* Pass number used for enumerating the pass list. This differs from + static_pass_number in that the numbering is sequential and all passes + have a meaningful number assigned. */ + int pass_number; + protected: gcc::context *m_ctxt; }; Index: gcc/passes.c =================================================================== --- gcc/passes.c (revision 253327) +++ gcc/passes.c (working copy) @@ -899,6 +899,35 @@ pass_manager::create_pass_tab (void) con static bool override_gate_status (opt_pass *, tree, bool); +/* Enumerate pass list PASS starting with counter COUNTER. */ + +static int +enumerate_pass_list (opt_pass *pass, int counter) +{ + do + { + pass->pass_number = ++counter; + if (pass->sub) + counter = enumerate_pass_list (pass->sub, counter); + pass = pass->next; + } + while (pass); + return counter; +} + +/* Enumerate all optimization passes. */ + +void +pass_manager::enumerate_passes () const +{ + int counter = 0; + counter = enumerate_pass_list (all_lowering_passes, counter); + counter = enumerate_pass_list (all_small_ipa_passes, counter); + counter = enumerate_pass_list (all_regular_ipa_passes, counter); + counter = enumerate_pass_list (all_late_ipa_passes, counter); + counter = enumerate_pass_list (all_passes, counter); +} + /* Dump the instantiated name for PASS. IS_ON indicates if PASS is turned on or not. */ @@ -1508,6 +1537,9 @@ pass_manager::register_pass (struct regi XDELETE (added_pass_nodes); added_pass_nodes = next_node; } + + /* Update the pass enumeration. */ + enumerate_passes (); } /* Construct the pass tree. The sequencing of passes is driven by @@ -1614,6 +1646,9 @@ pass_manager::pass_manager (context *ctx register_dump_files (all_regular_ipa_passes); register_dump_files (all_late_ipa_passes); register_dump_files (all_passes); + + /* Enumerate passes. */ + enumerate_passes (); } static void