This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
How to add pass filtering for -fopt-info
- From: Sharad Singhai <singhai at google dot com>
- To: gcc <gcc at gcc dot gnu dot org>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, David Li <davidxl at google dot com>
- Date: Tue, 16 Oct 2012 01:15:13 -0700
- Subject: How to add pass filtering for -fopt-info
Hi,
I added -fopt-info option in r191883. This option allows one to
quickly see high-level optimization info instead of scanning several
verbose dump files.
However, -fopt-info implementation is not complete as it dumps
info from all the passes. It would be nice to add high level
pass-level filtering to make it more useful. For example, if someone
is interested only in loop optimizations, they could say
-fopt-info-optimized-loop ==> show me high-level info about
optimized locations from all the loop passes.
To achieve this I am considering these two alternatives
A) Have an additional field in the 'struct opt_pass'. It is similar to
pass name (which is already used for generating the dump file name),
this new field will indicate the high-level name which can be used for
-fopt-info. For example,
struct gimple_opt_pass pass_loop_distribution =
{
{
GIMPLE_PASS,
"ldist", /* name */
"loop", ===> New field indicating it is a "loop" optimization pass
...
}
}
Multiple loop passes would have the same opt info name "loop" under
this scheme.
B) Have an additional method, something like 'register_opt_info ()'
which would associate a high-level name with the current pass.
So for example, the call to register would be inside the actual
execute method
tree_loop_distribution (void)
{
...
register_opt_info ("loop"); ==> associate this pass with "loop"
optimizatations
...
}
I think there are pros and cons of each.
A) has the benefit that each pass statically declares which high-level
optimization it belongs to, which is quite clear. However, the
disadvantage is that using an extra field would require a global
change as all the opt_pass static definitions would need to be
updated.
B) has the benefit that it is more flexible. The 'register_opt_info
()' needs to be called only on certain interesting passes, the other
passes would remain unchanged. Another advantage of B) is that a pass
could register for multiple high-level opt-info
names. (Though I don't know when it would be useful.) The downside is
that it is more error prone as any opt info dumps would not be
possible until corresponding registration is done.
I would appreciate comments on either of these alternatives. Perhaps
something else more appropriate for this purpose?
Thanks,
Sharad