This is the first patch for planned improvements to dump
infrastructure. Please reference the discussion in
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02088.html.
The following small patch allows selective tree and rtl dumps on
stderr instead of named files. Later -fopt-info can be implemented
In response to comments, I have updated the patch to support dumps in
user provided files via the option -fdump-xxx=. The
filenames stdout/stderr are treated specially, and are considered
standard streams.
Also updated documentation and a testcase. Okay for trunk?
Thanks,
Sharad
2012-05-08 Sha
On Mon, May 7, 2012 at 4:58 PM, Sharad Singhai wrote:
> This is the first patch for planned improvements to dump
> infrastructure. Please reference the discussion in
> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02088.html.
>
> The following small patch allows selective tree and rtl dumps on
> s
That is certainly a possibility. The original motivation was to
implement -fopt-info correctly. If there are other use cases, then I
can enhance the patch.
Thanks,
Sharad
On Mon, May 7, 2012 at 3:02 PM, Gabriel Dos Reis
wrote:
> On Mon, May 7, 2012 at 4:58 PM, Sharad Singhai wrote:
>> This is
On Tue, May 8, 2012 at 12:02 AM, Gabriel Dos Reis
wrote:
> On Mon, May 7, 2012 at 4:58 PM, Sharad Singhai wrote:
>> This is the first patch for planned improvements to dump
>> infrastructure. Please reference the discussion in
>> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02088.html.
>>
>> The
On Tue, May 8, 2012 at 11:46 PM, Sharad Singhai wrote:
> In response to comments, I have updated the patch to support dumps in
> user provided files via the option -fdump-xxx=. The
> filenames stdout/stderr are treated specially, and are considered
> standard streams.
I think - should also be tre
On Wed, May 9, 2012 at 1:51 AM, Andrew Pinski wrote:
> On Tue, May 8, 2012 at 11:46 PM, Sharad Singhai wrote:
>> In response to comments, I have updated the patch to support dumps in
>> user provided files via the option -fdump-xxx=. The
>> filenames stdout/stderr are treated specially, and are c
On Wed, May 9, 2012 at 1:46 AM, Sharad Singhai wrote:
[...]
> +@item -fdump-rtl-all=stderr
> +@opindex fdump-rtl-all=stderr
You do not need to have a separate index entry for '=stderr' or '=stdout'.
Rather, expand the description to state this in all the documentation
for -fdump-xxx=yyy.
[...]
Thanks for your suggestions/comments. I have updated the patch and
documentation. It supports the following usage:
gcc -fdump-tree-all=tree.dump -fdump-tree-pre=stdout
-fdump-rtl-ira=ira.dump
Here all tree dumps except the PRE are output into tree.dump, PRE dump
goes to stdout and the IRA du
Bummer. I was thinking to reserve '=' for selective dumping:
-fdump-tree-pre=
I guess this can be achieved via @
-fdump-tree-pre@
-fdump-tree-pre=@
Another issue -- I don't think the current precedence rule is correct.
Consider that -fopt-info=2 will be mapped to
-fdump-tree-all-transform-
On Thu, May 10, 2012 at 2:31 AM, Xinliang David Li wrote:
> Bummer. I was thinking to reserve '=' for selective dumping:
>
> -fdump-tree-pre=
>
> I guess this can be achieved via @
>
> -fdump-tree-pre@
>
> -fdump-tree-pre=@
>
>
> Another issue -- I don't think the current precedence rule is corr
Okay, I have restored the original behavior where standard streams
were considered weak. Thus in case of a conflict, the
standard streams have lower precedence. For example,
gcc -O2 -fdump-tree-pre=stdout -fdump-tree-pre ...
does the PRE dump in auto numbered file since stdout has
I like your suggestion and support the end goal you have. I don't
like the -fopt-info behavior to interfere with regular -fdump-xxx
options either.
I think we should stage the changes in multiple steps as originally
planned. Is Sharad's change good to be checked in for the first stage?
After thi
On Thu, May 10, 2012 at 6:28 PM, Xinliang David Li wrote:
> I like your suggestion and support the end goal you have. I don't
> like the -fopt-info behavior to interfere with regular -fdump-xxx
> options either.
>
> I think we should stage the changes in multiple steps as originally
> planned. Is
On Fri, May 11, 2012 at 1:49 AM, Richard Guenther
wrote:
> On Thu, May 10, 2012 at 6:28 PM, Xinliang David Li wrote:
>> I like your suggestion and support the end goal you have. I don't
>> like the -fopt-info behavior to interfere with regular -fdump-xxx
>> options either.
>>
>> I think we shoul
To be more specific, does the following match what your envisioned?
1) when multiple streams are specified for dumping, the information
will be dumped to all streams IF the new dumping interfaces are used
(see below). For legacy code, the default dump file will still be used
and the user specified
On Fri, May 11, 2012 at 8:11 PM, Xinliang David Li wrote:
> To be more specific, does the following match what your envisioned?
>
> 1) when multiple streams are specified for dumping, the information
> will be dumped to all streams IF the new dumping interfaces are used
> (see below). For legacy c
Sounds good.
On Sat, May 12, 2012 at 3:31 AM, Richard Guenther
wrote:
> On Fri, May 11, 2012 at 8:11 PM, Xinliang David Li wrote:
>> To be more specific, does the following match what your envisioned?
>>
>> 1) when multiple streams are specified for dumping, the information
>> will be dumped to
On Sat, May 12, 2012 at 11:05 AM, Xinliang David Li 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
On Sat, May 12, 2012 at 9:26 AM, Gabriel Dos Reis
wrote:
> On Sat, May 12, 2012 at 11:05 AM, Xinliang David Li
> 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 int
On Sat, May 12, 2012 at 6:39 PM, Xinliang David Li wrote:
> On Sat, May 12, 2012 at 9:26 AM, Gabriel Dos Reis
> wrote:
>> On Sat, May 12, 2012 at 11:05 AM, Xinliang David Li
>> wrote:
>>
>>> The downside is that the dump file format will look different from the
>>> stderr output which is less t
On Wed, Jun 6, 2012 at 10:58 PM, Sharad Singhai 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 cal
Ping.
Thanks,
Sharad
On Thu, Jun 7, 2012 at 10:16 PM, Sharad Singhai wrote:
> Okay, I have updated the attached patch so that the output from
> -ftree-vectorizer-verbose is considered diagnostic information and is
> always
> sent to stderr. Other functionality remains unchanged. Here is some
> m
On Fri, Jun 8, 2012 at 7:16 AM, Sharad Singhai wrote:
> Okay, I have updated the attached patch so that the output from
> -ftree-vectorizer-verbose is considered diagnostic information and is
> always
> sent to stderr. Other functionality remains unchanged. Here is some
> more context about this p
Thanks for your comments. Responses inline.
On Wed, Jun 13, 2012 at 4:48 AM, Richard Guenther
wrote:
> On Fri, Jun 8, 2012 at 7:16 AM, Sharad Singhai wrote:
>> Okay, I have updated the attached patch so that the output from
>> -ftree-vectorizer-verbose is considered diagnostic information and is
On Thu, Jun 14, 2012 at 8:58 AM, Sharad Singhai wrote:
> Thanks for your comments. Responses inline.
>
> On Wed, Jun 13, 2012 at 4:48 AM, Richard Guenther
> wrote:
>> On Fri, Jun 8, 2012 at 7:16 AM, Sharad Singhai wrote:
>>> Okay, I have updated the attached patch so that the output from
>>> -ft
On Wed, Jun 13, 2012 at 4:48 AM, Richard Guenther
wrote:
> On Fri, Jun 8, 2012 at 7:16 AM, Sharad Singhai wrote:
>> Okay, I have updated the attached patch so that the output from
>> -ftree-vectorizer-verbose is considered diagnostic information and is
>> always
>> sent to stderr. Other functiona
On Fri, Jun 15, 2012 at 7:47 AM, Sharad Singhai wrote:
> On Wed, Jun 13, 2012 at 4:48 AM, Richard Guenther
> wrote:
>> On Fri, Jun 8, 2012 at 7:16 AM, Sharad Singhai wrote:
>>> Okay, I have updated the attached patch so that the output from
>>> -ftree-vectorizer-verbose is considered diagnostic
On Tue, Jul 3, 2012 at 11:07 PM, Sharad Singhai wrote:
> Apologies for the spam. Attempting to resend the patch after shrinking it.
>
> I have updated the attached patch to use a new dump message
> classification system for the vectorizer. It currently uses four
> classes, viz, MSG_OPTIMIZED_LOCAT
Hi,
The tests gcc.dg/vect/vect-82_64.c and gcc.dg/vect/vect-83_64.c are
failing on powerpc*-*-* (see for instance
http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg01054.html ).
This is fixed with the following patch
diff -up gcc/testsuite/gcc.dg/vect/vect-82_64.c
../work/gcc/testsuite/gcc.dg/vec
Ping.
Thanks,
Sharad
Sharad
On Wed, Sep 5, 2012 at 10:34 AM, Sharad Singhai wrote:
> Ping.
>
> Thanks,
> Sharad
>
> Sharad
>
>
>
>
> On Fri, Aug 24, 2012 at 1:06 AM, Sharad Singhai wrote:
>>
>> Sorry about the delay. Please see comments inline.
>>
>> On Wed, Jul 4, 2012 at 6:33 AM, Richard Gue
Can you resend your patch in text form (also need to resolve the
latest conflicts) so that it can be commented inline?
Please also provide as summary a more up-to-date description of
1) Command line option syntax and semantics
2) New dumping APIs and semantics
3) Conversion changes
Looking at the
On Wed, Sep 12, 2012 at 12:30 PM, Richard Guenther
wrote:
> On Wed, Sep 12, 2012 at 10:12 AM, Sharad Singhai wrote:
>> Thanks for your comments. Please see my responses inline.
>>
>> On Tue, Sep 11, 2012 at 1:16 PM, Xinliang David Li
>> wrote:
>>> Can you resend your patch in text form (also ne
On Wed, Sep 12, 2012 at 6:46 PM, Xinliang David Li wrote:
> On Wed, Sep 12, 2012 at 3:30 AM, Richard Guenther
> wrote:
>> On Wed, Sep 12, 2012 at 10:12 AM, Sharad Singhai wrote:
>>> Thanks for your comments. Please see my responses inline.
>>>
>>> On Tue, Sep 11, 2012 at 1:16 PM, Xinliang David
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, 20
> Is -fopt-info-rtl-all also accepted?
Currently it is accepted. However, based on the recent comments, I am
going to remove the pass name from the flags.
>
> It would be useful to have a good default for -fopt-info so that users
> can get high level info about optimizations without having to spe
Yes, indeed.
thanks,
David
On Thu, Sep 13, 2012 at 4:08 AM, Richard Guenther
wrote:
> On Wed, Sep 12, 2012 at 6:46 PM, Xinliang David Li wrote:
>> On Wed, Sep 12, 2012 at 3:30 AM, Richard Guenther
>> wrote:
>>> On Wed, Sep 12, 2012 at 10:12 AM, Sharad Singhai wrote:
Thanks for your comm
On Tue, Sep 18, 2012 at 1:48 AM, Sharad Singhai wrote:
> In response to the recent comments, I have updated the patch to do the
> following:
>
> - Remove pass handling from -fopt-info
> - Support additional flags in regular dumps
>
> I have massaged the options so that they have the following (hop
On Sep 18, 2012 8:43 AM, "Xinliang David Li" wrote:
>
> On Tue, Sep 18, 2012 at 1:48 AM, Sharad Singhai wrote:
> > In response to the recent comments, I have updated the patch to do the
> > following:
> >
> > - Remove pass handling from -fopt-info
> > - Support additional flags in regular dumps
>
On Tue, Sep 18, 2012 at 10:48 AM, Sharad Singhai wrote:
> In response to the recent comments, I have updated the patch to do the
> following:
>
> - Remove pass handling from -fopt-info
> - Support additional flags in regular dumps
>
> I have massaged the options so that they have the following (ho
Ping.
On Mon, Sep 24, 2012 at 10:10 PM, Sharad Singhai wrote:
> Ping.
Some minor issues:
* c/c-decl.c (c_write_global_declarations): Use different method to
determine if the dump has ben initialized.
* cp/decl2.c (cp_write_global_declarations): Ditto.
* testsuite/gcc.ta
Thanks for the review. A couple of comments inline:
> Some minor issues:
>
> * c/c-decl.c (c_write_global_declarations): Use different method to
> determine if the dump has ben initialized.
> * cp/decl2.c (cp_write_global_declarations): Ditto.
> * testsuite/gcc.targ
On Thu, Sep 27, 2012 at 4:35 AM, Sharad Singhai wrote:
> Thanks for the review. A couple of comments inline:
>
>> Some minor issues:
>>
>> * c/c-decl.c (c_write_global_declarations): Use different method to
>> determine if the dump has ben initialized.
>> * cp/decl2.c (cp_w
Resend to gcc-patches
I have addressed the comments by fixing all the minor issues,
bootstrapped and tested on x86_64. I did the recommended reshuffling
by moving non-tree code from tree-dump.c into a new file dumpfile.c.
I committed two successive revisions
r191883 Main patch with the dump infra
On Sun, Sep 30, 2012 at 11:36 PM, Sharad Singhai wrote:
> Resend to gcc-patches
>
> I have addressed the comments by fixing all the minor issues,
> bootstrapped and tested on x86_64. I did the recommended reshuffling
> by moving non-tree code from tree-dump.c into a new file dumpfile.c.
>
> I comm
I am sorry, I didn't enable all the languages. Will fix the fortran
test breakage shortly.
Thanks,
Sharad
Sharad
On Mon, Oct 1, 2012 at 4:50 AM, H.J. Lu wrote:
> On Sun, Sep 30, 2012 at 11:36 PM, Sharad Singhai wrote:
>> Resend to gcc-patches
>>
>> I have addressed the comments by fixing all t
On Mon, Oct 1, 2012 at 6:49 AM, Sharad Singhai wrote:
> I am sorry, I didn't enable all the languages. Will fix the fortran
> test breakage shortly.
It is not just Fortran. There are some failures in C testcases.
> Thanks,
> Sharad
> Sharad
>
>
> On Mon, Oct 1, 2012 at 4:50 AM, H.J. Lu wrote:
On Mon, Oct 1, 2012 at 6:52 AM, H.J. Lu wrote:
> On Mon, Oct 1, 2012 at 6:49 AM, Sharad Singhai wrote:
>> I am sorry, I didn't enable all the languages. Will fix the fortran
>> test breakage shortly.
>
> It is not just Fortran. There are some failures in C testcases.
I checked and those files l
On Mon, Oct 1, 2012 at 3:55 PM, Sharad Singhai wrote:
> On Mon, Oct 1, 2012 at 6:52 AM, H.J. Lu wrote:
>> On Mon, Oct 1, 2012 at 6:49 AM, Sharad Singhai wrote:
>>> I am sorry, I didn't enable all the languages. Will fix the fortran
>>> test breakage shortly.
>>
>> It is not just Fortran. There
Okay, I am retesting without any special configs and with multilibs as
you suggested.
Thanks,
Sharad
On Mon, Oct 1, 2012 at 7:00 AM, Richard Guenther
wrote:
> On Mon, Oct 1, 2012 at 3:55 PM, Sharad Singhai wrote:
>> On Mon, Oct 1, 2012 at 6:52 AM, H.J. Lu wrote:
>>> On Mon, Oct 1, 2012 at 6:49
Your change on September 30th, breaks the powerpc port because the
REPORT_DETAILS value in the enumeration is no longer there, and the
rs6000_density_test function was using that. Please in the future, when you
are making global changes, grep for uses of enum values in all of the machine
dependent
On Mon, Oct 01, 2012 at 02:02:26PM -0400, Michael Meissner wrote:
> Your change on September 30th, breaks the powerpc port because the
> REPORT_DETAILS value in the enumeration is no longer there, and the
> rs6000_density_test function was using that. Please in the future, when you
> are making gl
On Mon, Oct 1, 2012 at 1:27 PM, Michael Meissner
wrote:
> On Mon, Oct 01, 2012 at 02:02:26PM -0400, Michael Meissner wrote:
>> Your change on September 30th, breaks the powerpc port because the
>> REPORT_DETAILS value in the enumeration is no longer there, and the
>> rs6000_density_test function w
I have mailed a patch to fix test failures caused by r191884. Waiting
for an okay.
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00109.html
Thanks,
Sharad
Sharad
On Mon, Oct 1, 2012 at 11:39 AM, Gabriel Dos Reis
wrote:
> On Mon, Oct 1, 2012 at 1:27 PM, Michael Meissner
> wrote:
>> On Mon, Oct
On Mon, Oct 1, 2012 at 8:39 PM, Gabriel Dos Reis
wrote:
> On Mon, Oct 1, 2012 at 1:27 PM, Michael Meissner
> wrote:
>> On Mon, Oct 01, 2012 at 02:02:26PM -0400, Michael Meissner wrote:
>>> Your change on September 30th, breaks the powerpc port because the
>>> REPORT_DETAILS value in the enumerati
On Tue, Oct 2, 2012 at 4:31 AM, Richard Guenther
wrote:
> On Mon, Oct 1, 2012 at 8:39 PM, Gabriel Dos Reis
> wrote:
>> On Mon, Oct 1, 2012 at 1:27 PM, Michael Meissner
>> wrote:
>>> On Mon, Oct 01, 2012 at 02:02:26PM -0400, Michael Meissner wrote:
Your change on September 30th, breaks the p
57 matches
Mail list logo