On Wed, Oct 31, 2012 at 8:20 AM, Sharad Singhai <sing...@google.com> wrote:
> I am attaching an updated patch with comments inline.
>
> On Tue, Oct 30, 2012 at 9:04 AM, Xinliang David Li <davi...@google.com> wrote:
>> On Tue, Oct 30, 2012 at 8:28 AM, Richard Biener
>> <richard.guent...@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.
@@ -503,7 +509,7 @@ register_one_dump_file (struct opt_pass *pass)
name = name ? name + 1 : pass->name;
dot_name = concat (".", name, num, NULL);
if (pass->type == SIMPLE_IPA_PASS || pass->type == IPA_PASS)
- prefix = "ipa-", flags = TDF_IPA;
+ prefix = "ipa-", flags = TDF_IPA, optgroup_flags |= OPTGROUP_IPA;
please do not use compound statements.
Otherwise ok if testing is ok.
Thanks,
Richard.
> Thanks,
> Sharad
