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: [PATCH] Convert more passes to new dump framework

On Thu, Aug 29, 2013 at 3:05 AM, Richard Biener
<> 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 Johnson | Software Engineer | | 408-460-2413

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