| Message ID | 4F8EED58.6050801@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
Why only rtl? Minor suggestion: use ir or il may be more intuitive: -fdump-rtl-all-ir thanks, David On Wed, Apr 18, 2012 at 9:35 AM, Andrew Stubbs <ams@codesourcery.com> wrote: > This patch scratches an itch I've had for a while. > > Basically it just reduces all tree and RTL dumps to just the function dump. > This means that the files are easier to diff. > > This can still be combined with the other options of course: > e.g. -fdump-rtl-all-quiet-slim is quite nice. > > Obviously, most of the passes do dumps by calling fprintf directly, and I > don't want to edit each and every case, so I've implemented this by setting > dump_file=NULL in execute_one_pass. > > OK to commit? > > Andrew
On 18/04/12 19:00, Xinliang David Li wrote: > Why only rtl? Minor suggestion: use ir or il may be more intuitive: > -fdump-rtl-all-ir It isn't only RTL. It also applies to the tree dumps. I did say so in my message, although all the examples were RTL. Also, "ir" and "il" are not more intuitive to me. You're going to have to explain what those mean. "Intermediate Representation?" Andrew
On Wed, Apr 18, 2012 at 12:42 PM, Andrew Stubbs <ams@codesourcery.com> wrote: > On 18/04/12 19:00, Xinliang David Li wrote: >> >> Why only rtl? Minor suggestion: use ir or il may be more intuitive: >> -fdump-rtl-all-ir > > > It isn't only RTL. It also applies to the tree dumps. I did say so in my > message, although all the examples were RTL. > > Also, "ir" and "il" are not more intuitive to me. You're going to have to > explain what those mean. "Intermediate Representation?" yes, it means intermediate representation. The dump flags can be roughly categorized like this: 1) first level flags to control what to dump 2) second level flags to control how the dump is done 3) first level flags to control where to dump (to be added) 4) first level flags to control when to dump (to be added) Flags in category 1) -------------------------- There are four types of information that can be dumped (should be controlled by flag set 1) ): 1.a) transformation decisions -- such as -fdump-tree-vectorize-transformations (to be added) 1.b) Intermediate representations --> related to what you propose 1.c) debug traces (flag to be added) 1.d) stats (memory usage, etc). The default should be dumping all 4 types, but can be individually controlled, e.g, dump transformation + IR: -fdump-tree-all-transformations-ir 1.a) can be used to implement -fopt-info option (to dump optimization info notes to stderr) -- there is a separate discussion thread on this Category 2) --------------- Most of the existing flags are here. For instance, the following second level flags are used to control IR dump: vops, slim, verbose (may need to be renamed), raw, blocks, address, etc. The flag 'details' is used to control the debug trace level. Category 3) ---------------- The new proposed flag is to allow the dump to be emitted to stderr: -fdump-tree-all-transformations-stderr Category 4) --------------- These are new proposed flags: To control IR dump before the pass or after the pass. Sharad will be working on cleaning up the dump infrastructure, so that work will cover what you need. thanks, David > > Andrew
On 18/04/12 22:09, Xinliang David Li wrote: > Flags in category 1) > -------------------------- > There are four types of information that can be dumped (should be > controlled by flag set 1) ): > 1.a) transformation decisions -- such as > -fdump-tree-vectorize-transformations (to be added) > 1.b) Intermediate representations --> related to what you propose > 1.c) debug traces (flag to be added) > 1.d) stats (memory usage, etc). That's all very nice, but apart from name bikeshedding, it shouldn't interfere with my patch at all. The same goes for most of the rest of your categories: the patches may conflict, but the purpose does not. > The default should be dumping all 4 types, but can be individually > controlled, e.g, dump transformation + IR: > -fdump-tree-all-transformations-ir Do you already have an implementation for this? If so, please post it and we'll let a maintainer choose which they like best. > Most of the existing flags are here. For instance, the following > second level flags are used to control IR dump: vops, slim, verbose > (may need to be renamed), raw, blocks, address, etc. The flag > 'details' is used to control the debug trace level. To me, the existing "(default), verbose, details" option set makes sense, and adding "quiet" to that set seemed appropriate. I'm not sure I like the idea of renaming existing options, even if they aren't likely to break much. > These are new proposed flags: To control IR dump before the pass or > after the pass. Why? Is there a case where the dump from after the previous pass is not the same as the dump before the next? With the exception of the "transformations" stuff, as you call it, perturbing my diffs, I've not had any problems in this area. Sharad will be working on cleaning up the dump infrastructure, so that > work will cover what you need. I look forward to seeing it. Hopefully the documentation will get a good once over as well! :) In the meantime, Mr Maintainers, can I commit my patch while we wait for the new world order? I'm happy to change the option name "quiet" to something else if necessary. Thanks Andrew
On Thu, Apr 19, 2012 at 5:58 AM, Andrew Stubbs <ams@codesourcery.com> wrote: > On 18/04/12 22:09, Xinliang David Li wrote: >> >> Flags in category 1) >> -------------------------- >> There are four types of information that can be dumped (should be >> controlled by flag set 1) ): >> 1.a) transformation decisions -- such as >> -fdump-tree-vectorize-transformations (to be added) >> 1.b) Intermediate representations --> related to what you propose >> 1.c) debug traces (flag to be added) >> 1.d) stats (memory usage, etc). > > > That's all very nice, but apart from name bikeshedding, it shouldn't > interfere with my patch at all. No -- I just want to let you know there is similar effort planed for better coordination. The maintainer will make a call on your patch. > > The same goes for most of the rest of your categories: the patches may > > To me, the existing "(default), verbose, details" option set makes sense, > and adding "quiet" to that set seemed appropriate. I'm not sure I like the > idea of renaming existing options, even if they aren't likely to break much. > It is confusing. 'verbose' applies to IR, while 'details' applies to debug traces. > >> These are new proposed flags: To control IR dump before the pass or >> after the pass. > > > Why? Is there a case where the dump from after the previous pass is not the > same as the dump before the next? For productivity -- without it, you either need to remember all pass ordering, or always dump-all --> the latter can be prohibitive for very large files. thanks, David
On 19/04/12 17:21, Xinliang David Li wrote: >> To me, the existing "(default), verbose, details" option set makes sense, >> and adding "quiet" to that set seemed appropriate. I'm not sure I like the >> idea of renaming existing options, even if they aren't likely to break much. > > It is confusing. 'verbose' applies to IR, while 'details' applies to > debug traces. Ah, so -fdump-rtl-all-quiet-verbose might actually be meaningful? Interesting, I had not spotted that. Like I said, the documentation could use a once over. >>> These are new proposed flags: To control IR dump before the pass or >>> after the pass. >> >> Why? Is there a case where the dump from after the previous pass is not the >> same as the dump before the next? > > For productivity -- without it, you either need to remember all pass > ordering, or always dump-all --> the latter can be prohibitive for > very large files. Fair enough. Andrew
On 19/04/12 13:58, Andrew Stubbs wrote: > In the meantime, Mr Maintainers, can I commit my patch while we wait for > the new world order? I'm happy to change the option name "quiet" to > something else if necessary. Ping. I think David may have a point about 'quiet' being an inappropriate name for this option. He proposed 'ir' which I don't like but will do the job just fine. Ok, with that change? Andrew
Ping. On 02/05/12 10:49, Andrew Stubbs wrote: > On 19/04/12 13:58, Andrew Stubbs wrote: >> In the meantime, Mr Maintainers, can I commit my patch while we wait for >> the new world order? I'm happy to change the option name "quiet" to >> something else if necessary. > > Ping. > > I think David may have a point about 'quiet' being an inappropriate name > for this option. He proposed 'ir' which I don't like but will do the job > just fine. > > Ok, with that change? > > Andrew >
2012-04-18 Andrew Stubbs <ams@codesourcery.com> gcc/ * tree-pass.h (TDF_QUIET): New define. * tree-dump.c (dump_options): Add "quiet". * passes.c (execute_one_pass): Handle TDF_QUIET. * doc/invoke.texi: Document -fdump-tree-quiet. Mention -fdump-rtl-pass-options form. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index a13ddfa..1082b13 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -5229,6 +5229,7 @@ of option arguments. @item -d@var{letters} @itemx -fdump-rtl-@var{pass} +@itemx -fdump-rtl-@var{pass}-@var{options} @opindex d Says to make debugging dumps during compilation at times specified by @var{letters}. This is used for debugging the RTL-based passes of the @@ -5244,6 +5245,9 @@ explicitly specified and it is not an executable, otherwise it is the basename of the source file. These switches may have different effects when @option{-E} is used for preprocessing. +The @option{-fdump-rtl-@var{pass}-@var{options}} form uses the same +@var{options} as @option{-fdump-tree-@var{pass}-@var{options}}. + Debug dumps can be enabled with a @option{-fdump-rtl} switch or some @option{-d} option @var{letters}. Here are the possible letters for use in @var{pass} and @var{letters}, and their meanings: @@ -5672,9 +5676,11 @@ Enable showing the tree dump for each statement. Enable showing the EH region number holding each statement. @item scev Enable showing scalar evolution analysis details. +@item quiet +Disable all but the function dump. @item all -Turn on all options, except @option{raw}, @option{slim}, @option{verbose} -and @option{lineno}. +Turn on all options, except @option{raw}, @option{slim}, @option{verbose}, +@option{lineno} and @option{quiet}. @end table The following tree dumps are possible: diff --git a/gcc/passes.c b/gcc/passes.c index a786881..e946c63 100644 --- a/gcc/passes.c +++ b/gcc/passes.c @@ -2078,8 +2078,16 @@ execute_one_pass (struct opt_pass *pass) /* Do it! */ if (pass->execute) { + FILE *tmp = dump_file; + + if (dump_flags & TDF_QUIET) + dump_file = NULL; + todo_after = pass->execute (); do_per_function (clear_last_verified, NULL); + + if (dump_flags & TDF_QUIET) + dump_file = tmp; } /* Stop timevar. */ diff --git a/gcc/tree-dump.c b/gcc/tree-dump.c index 3e89cdf..81f3262 100644 --- a/gcc/tree-dump.c +++ b/gcc/tree-dump.c @@ -824,9 +824,11 @@ static const struct dump_option_value_info dump_options[] = {"nouid", TDF_NOUID}, {"enumerate_locals", TDF_ENUMERATE_LOCALS}, {"scev", TDF_SCEV}, + {"quiet", TDF_QUIET}, {"all", ~(TDF_RAW | TDF_SLIM | TDF_LINENO | TDF_TREE | TDF_RTL | TDF_IPA | TDF_STMTADDR | TDF_GRAPH | TDF_DIAGNOSTIC | TDF_VERBOSE - | TDF_RHS_ONLY | TDF_NOUID | TDF_ENUMERATE_LOCALS | TDF_SCEV)}, + | TDF_RHS_ONLY | TDF_NOUID | TDF_ENUMERATE_LOCALS | TDF_SCEV + | TDF_QUIET)}, {NULL, 0} }; diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h index 6f1fd6a..ed47dd1 100644 --- a/gcc/tree-pass.h +++ b/gcc/tree-pass.h @@ -84,6 +84,7 @@ enum tree_dump_index #define TDF_ENUMERATE_LOCALS (1 << 22) /* Enumerate locals by uid. */ #define TDF_CSELIB (1 << 23) /* Dump cselib details. */ #define TDF_SCEV (1 << 24) /* Dump SCEV details. */ +#define TDF_QUIET (1 << 25) /* Dump only function content. */ /* In tree-dump.c */