Re: How to add pass filtering for -fopt-info

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Oct 16, 2012 at 10:15 AM, Sharad Singhai <singhai@google.com> wrote:
> 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?

I don't like B), it is unlike everything else a pass does.  You seem to
use the new field to indicate a group - that makes it a flat hierarchy
which might make it limiting (for example 'vect' may include both loop
and scalar vectorization, but would 'loop' also include loop vectorization?).
Using a bitmask and an enum would be my preference for this reason
(similar to how we have TDF_ flags).  Loop vectorization would then
be vect|loop for example.

Richard.

> Thanks,
> Sharad