Re: [PATCH, RFC] Add a pass counter for "are we there yet" purposes

[Richard Biener <richard dot guenther at gmail dot 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