This is the mail archive of the
mailing list for the GCC project.
Re: How to add pass filtering for -fopt-info
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Sharad Singhai <singhai at google dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>, David Li <davidxl at google dot com>
- Date: Tue, 16 Oct 2012 13:35:35 +0200
- Subject: Re: How to add pass filtering for -fopt-info
- References: <CAKxPW64OTE4Zix1Gg+VX--EtMHEQuPmwDOKMupeHnBoURXSauQ@mail.gmail.com>
On Tue, Oct 16, 2012 at 10:15 AM, Sharad Singhai <email@example.com> wrote:
> 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 =
> "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"
> 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
> 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.