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: [RFC] Do we want hierarchical options & encapsulation in a class


On 05/15/2017 01:18 PM, Nathan Sidwell wrote:
> On 05/15/2017 05:39 AM, Martin Liška wrote:
>> Thanks Martin for feedback! After I spent quite some time with fiddling with
>> the options, I'm not convinced we should convert options to more hierarchical
> 
> I'll respond to Martin's email properly separates, but while we're on dump redesign, here's a WIP patch I whipped up on Friday for the modules branch.  This tries to move the language-specific options to a dynamic registration mechanism, rather than hard wire them into dumpfile.[hc]. There were some awkward pieces due to the current structure of dumpfile registration.
> 
> I took the -fdump-class-heirachy and -fdump-translation-unit and turned them into -fdump-lang-class and -fdump-lang-translation.  Unfortunately the current LANG_HOOKS_INIT_OPTIONS is run rather too late to register these dumps so that they get nice low numbers.  That's because gcc::context::context () both creates the dump manager and then immediately creates all the optimization passes:
>   m_dumps = new gcc::dump_manager ();
>   /* Allow languages to register dumps before passes.  */
>   lang_hooks.register_dumps (m_dumps);
>   m_passes = new gcc::pass_manager (this);
> 
> As you can see i wedged a new lang hook between.  That's a little unpleasant -- perhaps
>   m_passes = new gcc::pass_manager (this);
> should be done later? Or the lang dumps could be unnumbered -- it is jarring for them to be numbered as-if succeeding the optimization passes.
> 
> (I passed m_dumps as a void * purely to avoid header file jiggery pokery at this step)
> 
> This patch does allow removing special class_dump_file handling from c-family/c-opts.c, which is nice.  It looks like -mdump-tree-original might be another candidate for dynamic registration?
> 
> thoughts?

Hello.

I like the idea and I believe we should do the same with single use (in a particular pass) dump files like:

  dump_file_info (".cgraph", "ipa-cgraph", DK_ipa, 0),
  dump_file_info (".type-inheritance", "ipa-type-inheritance", DK_ipa, 0),
  dump_file_info (".ipa-clones", "ipa-clones", DK_ipa, 0),
  dump_file_info (".tu", "translation-unit", DK_lang, 1),
  dump_file_info (".class", "class-hierarchy", DK_lang, 2),
  dump_file_info (".original", "tree-original", DK_tree, 3),
  dump_file_info (".gimple", "tree-gimple", DK_tree, 4),
  dump_file_info (".nested", "tree-nested", DK_tree, 5),

Martin

> 
> nathan
> 


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