From: Richard Biener <richard.guenther@gmail.com>
To: gcc-patches@gcc.gnu.org,Sandra Loosemore
<sandra@codesourcery.com>,"gcc-patches@gcc.gnu.org"
<gcc-patches@gcc.gnu.org>
Cc: mjambor@suse.cz,Jeff Law <law@redhat.com>,Jakub Jelinek
<jakub@redhat.com>
Subject: Re: [PATCH, RFC] Add a pass counter for "are we there yet" purposes
Date: Mon, 16 Oct 2017 08:38:00 -0000 [thread overview]
Message-ID: <F0205BD0-B893-47C4-9A91-28BAE58CC7FA@gmail.com> (raw)
In-Reply-To: <59E445EA.5030909@codesourcery.com>
On October 16, 2017 7:38:50 AM GMT+02:00, Sandra Loosemore <sandra@codesourcery.com> 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.
>
>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.
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.
Richard.
>
>-Sandra
next prev parent reply other threads:[~2017-10-16 6:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 5:46 Sandra Loosemore
2017-10-16 8:38 ` Richard Biener [this message]
2017-10-16 16:00 ` Sandra Loosemore
2017-10-16 16:27 ` Richard Biener
2017-10-20 4:03 ` Sandra Loosemore
2017-10-23 10:21 ` Martin Jambor
2017-10-23 10:27 ` Jakub Jelinek
2017-10-23 11:07 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F0205BD0-B893-47C4-9A91-28BAE58CC7FA@gmail.com \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=law@redhat.com \
--cc=mjambor@suse.cz \
--cc=sandra@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).