This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro


Hi,

On Mon, Jul 22, 2013 at 03:22:33PM -0400, David Malcolm wrote:
> On Mon, 2013-07-22 at 20:25 +0200, Martin Jambor wrote:
> > On Wed, Jul 17, 2013 at 09:18:22PM -0400, David Malcolm wrote:
> > > gcc/
> > > 
> > > 	Explicitly number the instances of passes within passes.def.
> > > 
> > > 	This is needed by a subsequent patch so that we can create
> > > 	fields within the pipeline class for each pass instance (to help
> > > 	locate pass instances when debugging).
> > > 
> > 
> > I don't really understand what you want to achieve.  Are you sure the
> > benefits are worth the work necessary to implement the processing of
> > passes.def.in?  Especially given that we already initialize
> > static_pass_number at run time and copy stuff around in
> > make_pass_instance when it is already set.  I assume this would
> > somehow allow us to directly dump data of say forwprop3 as apposed to
> > forwprop2 to but that would require constant awareness of the sequence
> > number of the currently running pass, which I think is also unpleasant
> > and error-prone.
> > 
> > I mean, you may have perfectly legitimate reasons for doing this, I'm
> > just wondering whether we are perhaps over-engineering this a bit.
> 
> The main goal here is part of eliminating global variables from gcc [1],
> to be able to create:
> 
> class pipeline
> {
>   /* omitting various other fields for clarity */
> 
>   opt_pass *pass_warn_unused_result;
>   opt_pass *pass_diagnose_omp_blocks;
>   opt_pass *pass_diagnose_tm_blocks;
>   opt_pass *pass_mudflap_1;
>   opt_pass *pass_lower_omp;
>   opt_pass *pass_lower_cf;
>   opt_pass *pass_lower_tm;
>   opt_pass *pass_refactor_eh;
>   opt_pass *pass_lower_eh;
>   opt_pass *pass_build_cfg;
>   opt_pass *pass_warn_function_return;
>   opt_pass *pass_expand_omp;
>   opt_pass *pass_build_cgraph_edges;
>   opt_pass *pass_ipa_free_lang_data;
>   opt_pass *pass_ipa_function_and_variable_visibility;
>   opt_pass *pass_early_local_passes;
>   opt_pass *pass_fixup_cfg;
>   opt_pass *pass_init_datastructures;
>   /* etc */
>   opt_pass *pass_clean_state;
> };
> 
> without having to list all of the pass kinds again, thus reusing the
> pass description from passes.def.  Without the numbering, I couldn't see
> a good way to avoid duplicate field names in the class.  So the
> numbering gives us uniqueness of field names in that class (and also
> makes debugging slightly easier, but that's a minor side-benefit).
> 

I really think the easier debugging benefit is really very small, if
any.  Is there another one?  Otherwise, I wouldn't bother with
explicit static fields for each pass but just have a linked list of
them.  If we ever make the pass manager to really be a manager of some
sort, this will happen anyway.

And as far as gdb is concerned, I'd rather avoid typing:

p current_context->pipeline_for_Ox_except_Og->my_great_pass_with_long_name_number_2->my_array[1]->stuff
p current_context->pipeline_for_Ox_except_Og->my_great_pass_with_long_name_number_2->my_array[2]->stuff
p current_context->pipeline_for_Ox_except_Og->my_great_pass_with_long_name_number_2->my_array[3]->stuff

and instead do

set $d = (my_great_pass_class *) current_context->current_pass
p $d->my_array[1]->stuff
p $d->my_array[2]->stuff
p $d->my_array[3]->stuff

Or am I missing something?  Otherwise I'd just say don't bother with awk.

Thanks,

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]