This is the mail archive of the
mailing list for the GCC project.
Re: New dump infrastructure
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
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.
On Tue, Oct 16, 2012 at 11:42 PM, Sharad Singhai <firstname.lastname@example.org> 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)
>> 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.