This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: New dump infrastructure
On Tue, Oct 16, 2012 at 3:41 PM, Martin Jambor <mjambor@suse.cz> wrote:
> 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.
Indeed. I also wonder why dump_kind_p does not check if dumping is
active at all? Thus, inside check dump_file / alternate dump_file for NULL.
> 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?
Arguably a bug. Not sure why it was done this way.
> 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