This is the mail archive of the gcc@gcc.gnu.org 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


Hi,

The new dump infrastructure was committed shortly before the trunk
entered stage 3.

However, except the vectorization passes, other passes do not dump
anything in response to -fopt-info flags despite the documentation. I
can prepare patches for a couple more passes so that they output more
meaningful information, otherwise, the -fopt-info would remain largely
useless in 4.8. Also I suspect some other passes can be converted
relatively easily to use the new dump scheme.

Would it be acceptable to consider -fopt-info patches in stage 3? If
yes, I can send out a more detailed message about the conversion and
solicit for help.

Thanks,
Sharad

On Fri, Oct 19, 2012 at 12:19 PM, Sharad Singhai <singhai@google.com> wrote:
> 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


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