This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Fwd: New dump infrastructure
> 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