Re: [PATCH] Add option for dumping to stderr (issue6190057)

[Xinliang David Li <davidxl at google dot com>]

On Wed, Jun 6, 2012 at 10:58 PM, Sharad Singhai <singhai@google.com> wrote:
> Sorry about the delay. I have finally incorporated all the suggestions
> and reorganized the dump infrastructure a bit. The attached patch
> updates vectorizer passes so that instead of accessing global
> dump_file directly, these passes call dump_printf (FLAG, format, ...).
> The dump_printf can choose between two streams, one regular pass dump
> file, and another optional command line provided file. Currently, it
> doesn't discriminate and all the dump information goes to both the
> streams.
>
> Thus, for example,
>
> g++ -O2 v.cc -ftree-vectorize -fdump-tree-vect=foo.v -ftree-vectorizer-verbose=3

But the default form of dump option (-fdump-tree-vect) no longer
interferes with -ftree-vectorize-verbose=xxx output right? (this is
one of the main requirements). One dumped to the primary stream (named
dump file) and the other to the stderr -- the default diagnostic (alt)
stream.

David

>
> will output the verbose vectorizer information in both *.vect file and
> foo.v file. However, as I have converted only vectorizer passes so
> far, there is additional information in *.vect file which is not
> present in foo.v file. Once other passes are converted to use this
> scheme, then these two dump files should have identical output.
>
> Also note that in this patch -fdump-xxx=yyy format does not override
> any auto named dump files as in my earlier patches. Instead the dump
> information is output to both places when a command line dump file
> option is provided.
>
> To summarize:
> - instead of using dump_begin () / dump_end (), the passes should use
> dump_start ()/dump_finish (). These new variants do not return the
> dump_file. However, they still set the global dump_file/dump_flags for
> the benefit of other passes during the transition.
> - instead of directly printing to the dump_file, as in
> if (dump_file)
> ?fprintf (dump_file, ...);
>
> The passes should do
>
> dump_printf (dump_flag, ...);
> This will output to dump file(s) only when dump_flag is enabled for a
> given pass.
>
> I have bootstrapped and tested it on x86_64. Does it look okay?
>
> Thanks,
> Sharad
>
>
> On Mon, May 14, 2012 at 12:26 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Sat, May 12, 2012 at 6:39 PM, Xinliang David Li <davidxl@google.com> wrote:
>>> On Sat, May 12, 2012 at 9:26 AM, Gabriel Dos Reis
>>> <gdr@integrable-solutions.net> wrote:
>>>> On Sat, May 12, 2012 at 11:05 AM, Xinliang David Li <davidxl@google.com> wrote:
>>>>
>>>>> The downside is that the dump file format will look different from the
>>>>> stderr output which is less than ideal.
>>>>
>>>> BTW, why do people want to use stderr for dumping internal IRs,
>>>> as opposed to stdout or other files? ?That does not sound right.
>>>>
>>>
>>> I was talking about the transformation information difference. In
>>> stderr (where diagnostics go to), we may have
>>>
>>> foo.c: in function 'foo':
>>> foo.c:5:6: note: loop was vectorized
>>>
>>> but in dump file the format for the information may be different,
>>> unless we want to duplicate the machinery in diagnostics.
>>
>> So? ?What's the problem with that ("different" diagnostics)?
>>
>> Richard.
>>
>>> David
>>>
>>>> -- Gaby