This is the mail archive of the gcc@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: New dump infrastructure


Hi,

On Tue, Oct 16, 2012 at 01:21:29AM -0700, Sharad Singhai wrote:
> Hi,
> 
> This is a solicitation for help in converting passes to use the new
> dump infrastructure. More context below.

thanks for the email.  I hoped you'd summarize what the long thread
about this (that I lost track of) led to.  I'll be happy to convert
tree-sra and ipa-cp to the new framework.  Nevertheless, I have two
questions:

> 
> I have enhanced the dump infrastructure in r191883, r191884. These
> patches updated the tree/rtl dump facility so that passes do not
> reference the dump file directly, but instead use a different (and
> hopefully cleaner) API.
> 
> Instead of this
> 
>     if (dump_file)
>       fprintf (dump_file, ...);
> 
> the new style looks like this
> 
>     if (dump_kind_p (...))
>       dump_printf (...)

1. OK, I understand that e.g.

     if (dump_file && (dump_flags & TDF_DETAILS))

   should be converted into:
 
     if (dump_kind_p (TDF_DETAILS))

   But what about current code that does not care about dump_flags?
   E.g. converting simple

     if (dump_file) 

   to

     if (dump_kind_p (0))
    
   won't work, dump_kind_p will always return zero in such cases.

2. dump_kind_p seems to always return 0 if current_function_decl is
   NULL.  However, that precludes its use in IPA passes in which this
   can happen regularly.  Why is this restriction necessary?

Thanks,

Martin


> 
> In addition, I also added a new option -fopt-info. This option allows
> one to focus on high-level optimizations without scanning lots of
> verbose tree/rtl dump files. Currently, the following categories of
> optimization info are defined in dumpfile.c:
> 
> MSG_OPTIMIZED_LOCATIONS   /* -fopt-info optimized sources */
> MSG_MISSED_OPTIMIZATION   /* missed opportunities */
> MSG_NOTE                  /* general optimization info */
> MSG_ALL                   /* Dump all available info */
> 
> The same dump API works for both regular dumps as well as -fopt-info
> dumps. This is because the dump_kind_p () accepts a union of dump
> flags. These flags include all of the TDF_* flags as well as newly
> designed MSG_* flags.
> 
> For example, one could say
> 
>     if (dump_kind_p (MSG_OPTIMIZED_LOCATIONS | TDF_BLOCKS))
>       dump_printf (...);
> 
> This means that dump the info if either the -fopt-info-optimized or
> -ftree-<pass>-blocks options is given. The dump files for these dumps
> could be different, but individual passes do not need to worry about
> that. It is handled transparently.
> 
> Another feature is that this new dump infrastructure allows dumps to
> be redirected into command line named files (including stderr/stdout)
> instead of auto generated filenames.
> 
> Since the number of existing dump call sites is quite large, currently
> both old *and* new schemes are in use. The plan is to gradually
> transition passes to use the new dump infrastructure and deprecate the
> old dump style. This will also provide better optimization reports in
> future.
> 
> Now I am asking for help. :)
> 
> Thus far I have converted the vectorization passes to use the new dump
> scheme and output optimization details using -fopt-info. However, all
> other passes need help. It would be great if you could help convert
> your favorite pass (or two).
> 
> Thanks,
> Sharad


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