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

[Sharad Singhai <singhai at google dot com>]

That is a good point. Currently I am making a distinction between dump
flags and opt-info flags, but it is not necessary since the opt-info
flags can be thought of an extension of dump flags.

I will update the patch so that -fdump-tree-vect-optimized also works.

Thanks,
Sharad

On Thu, Sep 13, 2012 at 4:08 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Sep 12, 2012 at 6:46 PM, Xinliang David Li <davidxl@google.com> wrote:
>> On Wed, Sep 12, 2012 at 3:30 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Wed, Sep 12, 2012 at 10:12 AM, Sharad Singhai <singhai@google.com> wrote:
>>>> Thanks for your comments. Please see my responses inline.
>>>>
>>>> On Tue, Sep 11, 2012 at 1:16 PM, Xinliang David Li <davidxl@google.com> wrote:
>>>>> Can you resend your patch in text form (also need to resolve the
>>>>> latest conflicts) so that it can be commented inline?
>>>>
>>>> I tried to include inline patch earlier but my message was bounced
>>>> back from patches mailing list. I am trying it again.
>>>>
>>>>> Please also provide as summary a more up-to-date description of
>>>>> 1) Command line option syntax and semantics
>>>>
>>>> I added some documentation in the patch. Here are the relevant bits
>>>> from invoke.texi.
>>>>
>>>> `-fdump-tree-SWITCH-OPTIONS=FILENAME'
>>>>      Control the dumping at various stages of processing the
>>>>      intermediate language tree to a file.  The file name is generated
>>>>      by appending a switch-specific suffix to the source file name, and
>>>>      the file is created in the same directory as the output file. In
>>>>      case of `=FILENAME' option, the dump is output on the given file
>>>>      instead of the auto named dump files.
>>>>      ...
>>>>
>>>>     `=FILENAME'
>>>>           Instead of an auto named dump file, output into the given file
>>>>           name. The file names `stdout' and `stderr' are treated
>>>>           specially and are considered already open standard streams.
>>>>           For example,
>>>>
>>>>                gcc -O2 -ftree-vectorize -fdump-tree-vect-details=foo.dump
>>>>                     -fdump-tree-pre=stderr file.c
>>>>
>>>>           outputs vectorizer dump into `foo.dump', while the PRE dump
>>>>           is output on to `stderr'. If two conflicting dump filenames
>>>>           are given for the same pass, then the latter option
>>>>           overrides the earlier one.
>>>>
>>>> `-fopt-info-PASS'
>>>> `-fopt-info-PASS-OPTIONS'
>>>> `-fopt-info-PASS-OPTIONS=FILENAME'
>>>>      Controls optimization dumps from various passes. If the `-OPTIONS'
>>>>      form is used, OPTIONS is a list of `-' separated options which
>>>>      controls the details of the dump.  If OPTIONS is not specified, it
>>>>      defaults to `optimized'. If the FILENAME is not specified, it
>>>>      defaults to `stderr'. Note that the output FILENAME will be
>>>>      overwritten in case of multiple translation units. If a combined
>>>>      output from multiple the translation units is desired, `stderr'
>>>>      should be used instead.
>>>>
>>>>      The PASS could be one of the tree or rtl passes. The following
>>>>      options are available
>>>
>>> I don't like that we have -PASS here.  That makes it awfully similar
>>> to -fdump-PASS-OPTIONS=FILENAME.  Are we merely having
>>> -fopt-info because OPTIONS are "different"?
>>
>>
>> Having PASS is useful to do filtering. But as your said, the option
>> design here is very much oriented towards developers not end users
>> which fopt-info is also intended for.
>
> Just to add a comment here - -fopt-info is _only_ targeted at end users.
> Developers can use -fdump-tree-XXX=stderr now (which, with the correct
> pass / flags should produce identical output to -fopt-info - at least that
> was the whole point with the re-design of the dump API - to make it
> possible to implement -fopt-info in a way that it simply provides a nice
> interface to end-users to our existing dumping information.
>
> If it doesn't work like that right now we should make it work this way.
>
> Richard.