This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: New dump infrastructure
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Sharad Singhai <singhai at google dot com>
- Cc: Xinliang David Li <davidxl at google dot com>, gcc <gcc at gcc dot gnu dot org>, Martin Jambor <mjambor at suse dot cz>
- Date: Mon, 10 Dec 2012 20:02:37 +0100
- Subject: Re: New dump infrastructure
- References: <CAKxPW66qc3be22Ou=+NKF0e5_xdzTqdz_6trz3xoG-uBqz2ViA@mail.gmail.com> <20121016134148.GE30509@virgil.arch.suse.de> <CAKxPW67ykRNQyuL62ULrwKP_7xFUX=iLaX1H=aWYgZx4ry+kYQ@mail.gmail.com> <CAKxPW66dXzNYdti9m8q0wxO14cWzW2oXGX3wCyuqfoLZYQutFA@mail.gmail.com> <CAAkRFZ+jPYaAb2OBh6gfaz96A-_ZbMCmsOD+i_1Ms-Emw_LFXA@mail.gmail.com> <CAFiYyc3GZ50bx2T4vf7JtNBoJXSkXZF0SLQZ7Kr1dD_p=9KgGw@mail.gmail.com> <CAAkRFZJ7vqJidNV1S0-RTto=r0mrXB9hsZ5Xsx7rDOB+jNeE4A@mail.gmail.com> <CAFiYyc3HGC99MCNNbC-f2KXeYpX7-3A998NDvJ46YQx4dcV7nw@mail.gmail.com> <CAKxPW64COCvnA0U65CAAPA+BiRiHX2oWhMFCGyb30YWLKLfAwQ@mail.gmail.com> <CAFiYyc2wNunT1J=wuEf7TLAFjOEr0EiuvjmPekybSdbr03pnGw@mail.gmail.com> <CAAkRFZKmcPGJdgEFT6juNTHDNgwTs5NK9wu71cv86koam=zpMg@mail.gmail.com> <CAKxPW66Zx3YgrMq8Y8BW8WhQSoP-rbk9Vk0hZQ8wPQ_fEdFCOQ@mail.gmail.com> <CAKxPW65PboSJpEeXXxL9hsbBw=RiucCY597-bb9qCnNJ+J8oeg@mail.gmail.com>
On Mon, Dec 10, 2012 at 7:46 PM, Sharad Singhai <singhai@google.com> wrote:
> 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.
It should be decided on a case-by-case basis. What passes do you have in mind
that people are usually interested in in the context of -fopt-info?
Richard.
> 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