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
