Re: New dump infrastructure

[Xinliang David Li <davidxl at google dot com>]

A more simpler use model is not to guard the dump statement at all --
just express the intention a) what to dump; b) as what kind or to
where


1) I want to dump the something as optimized message:

  dump_printf (MSG_OPTIMIZED, "blah...")

  dump_printf_loc (MSG_OPTIMIZED, "blah")

2) I want to dump something together with tree dump regardless of the flag:

   dump_printf (TDF_TREE, ...);

3) I want to dump something with tree dump when detailed flags is set:

  dump_printf (TDF_DETAILS, ...);


The dumping code is not in the critical path, so the compile time
should not be a concern.

David


On Tue, Oct 16, 2012 at 11:42 PM, Sharad Singhai <singhai@google.com> wrote:
>> 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.
>
>
> Yes, you are right, the conversion is not completely mechanical and
> some care must be taken to preserve the original intent. I think one
> of the following might work in the case where a pass doesn't care
> about the dump_flags
>
> 1. use generic pass type flags, such as TDF_TREE, TDF_IPA, TDF_RTL
> which are guaranteed to be set depending on the pass type,
> 2. this dump statement might be a better fit for MSG_* flags if it
> deals with optimizations. Sometimes "if (dump_file) fpritnf
> (dump_file, ...)" idiom was used for these situations and now these
> sites might be perfect candidate for converting into MSG_* flags.
>
> If a cleaner way to handle this is desired, perhaps we can add an
> unconditional "dump_printf_always (...)", but currently it seems
> unnecessary. Note that for optimization messages which should always
> be printed, one can use MSG_ALL flag. However, no analogous flag
> exists for regular dumps. How about adding a corresponding TDF_ALL
> flag? Would that work?
>
>>
>>
>> 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?
>
>
> This is an oversight on my part. Originally, I wanted to be able to
> print source location information and this is a remnant of that. I am
> testing a patch to fix that.
>
> Thanks,
> Sharad