From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75899 invoked by alias); 16 Oct 2017 15:46:58 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 75890 invoked by uid 89); 16 Oct 2017 15:46:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=interest 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 15:46:55 +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 1e47bC-00049B-Qn from Sandra_Loosemore@mentor.com ; Mon, 16 Oct 2017 08:46:39 -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; Mon, 16 Oct 2017 08:46:36 -0700 Subject: Re: [PATCH, RFC] Add a pass counter for "are we there yet" purposes To: Richard Biener , References: <59E445EA.5030909@codesourcery.com> CC: , Jeff Law , Jakub Jelinek From: Sandra Loosemore Message-ID: <59E4D45B.4060207@codesourcery.com> Date: Mon, 16 Oct 2017 16:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SVR-ORW-MBX-09.mgc.mentorg.com (147.34.90.209) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-SW-Source: 2017-10/txt/msg01002.txt.bz2 On 10/16/2017 12:53 AM, Richard Biener wrote: > On October 16, 2017 7:38:50 AM GMT+02:00, Sandra Loosemore wrote: >> 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. >> >> [snip] > > I missed the post of why you need to know this. But as you noticed we're using reload_completed for similar purpose. There's also the possibility of setting/adding a pass property that split could provide and which you could query. We're using this to signal the various different lowering stages in GIMPLE for example. See the thread linked above. There was interest in a general mechanism to query the pass manager state instead of adding the bookkeeping to the nios2 backend or adding something to track the split1 pass to the target-independent parts of the compiler. After fiddling with it, though, I'm not sure this is an improvement. Maybe it would help the discussion if I got my nios2 patch set posted so that everybody could see the actual use case? It'll take me a few days to finish cleaning it up. -Sandra