On Tue, Oct 16, 2012 at 10:15 AM, Sharad Singhai <sing...@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
