Re: New dump infrastructure

[Sharad Singhai <singhai at google dot com>]

On Fri, Oct 19, 2012 at 12:03 PM, Xinliang David Li <davidxl@google.com> wrote:
> The one taking argument is changed to dump_enabled_phase (Sharad,
> should it be dump_enabled_phase_p ?).

Yes, I renamed the old method to dump_enabled_phase. I would rename it
further to dump_enabled_p to make it clear.

>
> Sharad, it may be better to throwing first a trivial patch that
> introduces dump_enabled_p () without argument, and leave the clean up
> of vectorizer code as a separate one. Do this earlier so that other
> contributors have time to cleanup the dumps. Please also resend to the
> email list to summarize the new standard way of debug/msg dump.

Yes, I would do that.

Thanks,
Sharad

>
> thanks,
>
> David
>
> On Fri, Oct 19, 2012 at 3:11 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Thu, Oct 18, 2012 at 7:22 PM, Sharad Singhai <singhai@google.com> wrote:
>>>> You still have the issue that // regular stuff may appear to possibly
>>>> clobber any_dump_enabled_p and thus repeated any_dump_enabled_p
>>>> checks are not optimized by the compiler (we don't have predicated
>>>> value-numbering (yet)).
>>>
>>>> So I prefer the guard.  I suppose after this discussion I prefer
>>>> a any_dump_enabled_p () guard instead of one with (repeated) flags.
>>>
>>> I have updated 'dump_enabled_p ()' a little bit in
>>> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01690.html to avoid
>>> checking of flags. If this looks better, I can update the guard
>>> conditions in vectorization passes from 'if (dump_kind_p (...))' to
>>> 'if (dump_enabled_p ())'.
>>
>> In the patch dump_enabled_p still has an integer argument.  But yes, after
>> this discussion please make it argument-less and work towards dropping
>> dump_kind_p (from the public interface at least).
>>
>> Thanks,
>> Richard.
>>
>>> Thanks,
>>> Sharad