This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New dump infrastructure

The one taking argument is changed to dump_enabled_phase (Sharad,
should it be dump_enabled_phase_p ?).

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.



On Fri, Oct 19, 2012 at 3:11 AM, Richard Biener
<> wrote:
> On Thu, Oct 18, 2012 at 7:22 PM, Sharad Singhai <> 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
>> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]