This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]