This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Convert more passes to new dump framework
- From: Teresa Johnson <tejohnson at google dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Xinliang David Li <davidxl at google dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Dehao Chen <dehao at google dot com>, Sharad Singhai <singhai at google dot com>
- Date: Thu, 29 Aug 2013 06:34:15 -0700
- Subject: Re: [PATCH] Convert more passes to new dump framework
- Authentication-results: sourceware.org; auth=none
- References: <CAAe5K+W=brFLz3kZYFXTYAE+T2yJVPF=z+vp+uKh4d+9vQXJKQ at mail dot gmail dot com> <20130806123714 dot GD3166 at virgil dot suse> <CAAe5K+VSDkg5sKB2nvraHFv66ZKGO84W6obYj+sBfGZ7F3-hpw at mail dot gmail dot com> <20130806160102 dot GE3166 at virgil dot suse> <CAAe5K+VCwEUz1BWAnAvPrSBT3DHsu1P-eF4-nQb9+aFyDyRORw at mail dot gmail dot com> <CAAe5K+Vu0en=WFJp5bw-Vu=n05LYGxvmmfctnZSWeS-5PKT=Rg at mail dot gmail dot com> <CAFiYyc17odz-dL10BcNcKc8B_QNE2KB538dunz45=1Kn67d-gw at mail dot gmail dot com> <CAAe5K+W2rXph_7YkB1DgyXK55s4XQVtV+yvGY3q30-1DEkSK7A at mail dot gmail dot com> <CAAkRFZLMOmQKrygnyQ2+abbR3ctWNjmtiKCC_Q+ppyu_i9HkVw at mail dot gmail dot com> <CAFiYyc3+B7ssKSDOrC805Lb3ESppkBOfU8RSJXjUFZRVNVUbCw at mail dot gmail dot com>
On Thu, Aug 29, 2013 at 3:05 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
>>>> Does
>>>> 'make newlines consitent' avoid all the spurious vertical spacing I see with
>>>> -fopt-info?
>>>
>>> Well, it helps get us there. The problem was that before, since
>>> dump_loc was not consistently emitting newlines, the calls had to emit
>>> their own newlines manually in the string to ensure there was a
>>> newline at all. I was thinking that once this is fixed I could go back
>>> and clean up all those calls by removing the newlines in the string. I
>>> could split this part into a separate patch and do both at once.
>>>
>>> However, after thinking about this some more this morning, I am
>>> wondering whether it is better to remove the newline emission
>>> completely from dump_loc and rely on the caller to put the newline in
>>> the string. The reason is that there are 2 high level interfaces to
>>> the new dump infrastructure, dump_printf() and dump_printf_loc(). Only
>>> the latter invokes dump_loc and gets the newline at the start of the
>>> message. The typical usage seems to be to start a message via
>>> dump_printf_loc, and then use dump_printf to emit parts of the message
>>> (thus not requiring a newline), but I think it may lead to problems to
>>> rely on this assumption.
>>>
>>> So if you agree, I will simply remove the newline altogether from
>>> dump_loc, and ensure that all clients of dump_printf/dump_printf_loc
>>> include a newline char as appropriate in the string they pass.
>>
>>
>> As a helper function, dump_loc should not blindly emit new line as it
>> has no context. I have tried to remove it, and push the newline to
>> higher level helpers -- it mostly works, but the vectorizer verbose
>> messages need serious clean up -- most of them assume that
>> dump_printf_loc does not end with new line, so that the expression
>> dump can follow in the same line (the message texts need clean up too
>> -- i do not like the === === in info messages).
>
> I know, but we should really do that cleanup.
I can work on this and will send a separate patch.
Teresa
--
Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413