Re: [PATCH] pass filtering for -fopt-info

[Sharad Singhai <singhai at google dot com>]

I am attaching an updated patch with comments inline.

On Tue, Oct 30, 2012 at 9:04 AM, Xinliang David Li <davidxl@google.com> wrote:
> On Tue, Oct 30, 2012 at 8:28 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:

>> What I'd expect from that would be both vec.miss and vec.opt being
>> populated ... (thus go away from the duality of dump files to
>> primary dump file plus a set of alternate dump files).

Yes, that would be an ideal behavior. Each pass currently has access
to only two dump files, its primary file and alternate file. If we
extend that to include a set, it would be cleaner and avoid some of
the issues like the following:

During testing, I found that even having any two different files for
-fopt-info is problematic. For example, consider

gcc ... -fopt-info-vec-optimized=vec.opt -fopt-info-loop-missed=loop.missed

Now 'loop' and 'vec' include overlapping passes and since we have only
one alternate file per pass, it can either be vec.opt or loop.missed,
and some information would be lost. If we have a set of files, we can
avoid this problem.

However, considering the stage 1 deadline, I don't think it is
feasible for this version. Instead, a set of alternate files can be
considered as a future extension. For now, having a default of
'stderr' works for the common use case. To further prevent confusion,
the current patch allows only one (non-stderr) file for -fopt-info and
a warning is printed as in  the example below

gcc ... -fopt-info-vec-optimized=vec.opt -fopt-info-loop-missed=loop.missed
cc1: warning: ignoring possibly conflicting option
'-fopt-info-loop-missed=loop.missed' [enabled by default]

Multiple dumps can be achieved using 'stderr' (default) instead.

gcc ... -fopt-info-vec-optimized -fopt-info-loop-missed

>>> I have updated the documentation to include -fopt-info examples, and
>>> added some details about -fopt-info command line conflicts.
>>
>> I like it overall, not sure if we want to pre-populate the OPTGROUP
>> set too much at this point.  Like what is 'tree' or 'rtl' to users?
>> nothing I think.
>> 'ipa' yes.  'lto'?  sounds redundant with 'ipa' to me.  'omp'?  we don't have
>> any optimizations here.

>
> OMP is a high level transformation, and it seems to be a good
> candidate group, but this part does not need to be designed now. For
> instance, there are a bunch of FDO related transformation (indirect
> call promotion, memcpy transformation etc), and coverage mismatch
> notes etc a good candidate to be filtered.

Yes, perhaps later, we can consider something like an 'fdo' group for
this purpose.

>> Thus please drop TREE, RTL, LTO and OMP for now.

Okay, I have removed 'tree', 'rtl', 'omp', 'lto' groups.

>>
>> Otherwise I'm leaving it for comments from other folks.
>>
>> Thanks,
>> Richard.
>>

I have updated the documentation and testing is ongoing.

Thanks,
Sharad

Attachment: opt_dump_group.5.patch
Description: Binary data