> 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
