This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Convert more passes to new dump framework


On Fri, Aug 30, 2013 at 6:27 PM, Xinliang David Li <davidxl@google.com> wrote:
> Except that in this form, the dump will be extremely large and not
> suitable for very large applications.

So?  You asked for it and you can easily grep the output before storing it
away.

> Besides, we might also want to
> use the same machinery (dump_printf_loc etc) for dump file dumping.
> The current behavior of using '-details' to turn on opt-info-all
> messages for dump files are not desirable.  How about the following:
>
> 1) add a new dump_kind modifier so that when that modifier is
> specified, the messages won't goto the alt_dumpfile (controlled by
> -fopt-info), but only to primary dump file. With this, the inline
> messages can be dumped via:
>
>    dump_printf_loc (OPT_OPTIMIZED_LOCATIONS | OPT_DUMP_FILE_ONLY, .....)
>
>
> 2) add more flags in -fdump- support:
>
>    -fdump-ipa-inline-opt   --> turn on opt-info messages only
>    -fdump-ipa-inline-optall --> turn on opt-info-all messages
>    -fdump-tree-pre-ir --> turn on GIMPLE dump only
>    -fdump-tree-pre-details --> turn on everything (ir, optall, trace)
>
> With this, developers can really just use
>
>
> -fdump-ipa-inline-opt=stderr for inline messages.
>
> thanks,
>
> David
>
> On Fri, Aug 30, 2013 at 1:30 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Thu, Aug 29, 2013 at 5:15 PM, Teresa Johnson <tejohnson@google.com> wrote:
>>> On Thu, Aug 29, 2013 at 3:04 AM, Richard Biener
>>> <richard.guenther@gmail.com> wrote:
>>>>>>> New patch below that removes this global variable, and also outputs
>>>>>>> the node->symbol.order (in square brackets after the function name so
>>>>>>> as to not clutter it). Inline messages with profile data look look:
>>>>>>>
>>>>>>> test.c:8:3: note: foobar [0] (99999000) inlined into foo [2] (1000)
>>>>>>> with call count 99999000 (via inline instance bar [3] (99999000))
>>>>>>
>>>>>> Ick.  This looks both redundant and cluttered.  This is supposed to be
>>>>>> understandable by GCC users, not only GCC developers.
>>>>>
>>>>> The main part that is only useful/understandable to gcc developers is
>>>>> the node->symbol.order in square brackes, requested by Martin. One
>>>>> possibility is that I could put that part under a param, disabled by
>>>>> default. We have something similar on the google branches that emits
>>>>> LIPO module info in the message, enabled via a param.
>>>>
>>>> But we have _dump files_ for that.  That's the developer-consumed
>>>> form of opt-info.  -fopt-info is purely user sugar and for usual translation
>>>> units it shouldn't exceed a single terminal full of output.
>>>
>>> But as a developer I don't want to have to parse lots of dump files
>>> for a summary of the major optimizations performed (e.g. inlining,
>>> unrolling) for an application, unless I am diving into the reasons for
>>> why or why not one of those optimizations occurred in a particular
>>> location. I really do want a summary emitted to stderr so that it is
>>> easily searchable/summarizable for the app as a whole.
>>>
>>> For example, some of the apps I am interested in have thousands of
>>> input files, and trying to collect and parse dump files for each and
>>> every one is overwhelming (it probably would be even if my input files
>>> numbered in the hundreds). What has been very useful is having these
>>> high level summary messages of inlines and unrolls emitted to stderr
>>> by -fopt-info. Then it is easy to search and sort by hotness to get a
>>> feel for things like what inlines are missing when moving to a new
>>> compiler, or compiling a new version of the source, for example. Then
>>> you know which files to focus on and collect dump files for.
>>
>> I thought we can direct dump files to stderr now?  So, just use
>> -fdump-tree-all=stderr
>>
>> and grep its contents.
>>
>>>>
>>>>> I'd argue that the other information (the profile counts, emitted only
>>>>> when using -fprofile-use, and the inline call chains) are useful if
>>>>> you want to understand whether and how critical inlines are occurring.
>>>>> I think this is the type of information that users focused on
>>>>> optimizations, as well as gcc developers, want when they use
>>>>> -fopt-info. Otherwise it is difficult to make sense of the inline
>>>>> information.
>>>>
>>>> Well, I doubt that inline information is interesting to users unless we are
>>>> able to aggressively filter it to what users are interested in.  Which IMHO
>>>> isn't possible - users are interested in "I have not inlined this even though
>>>> inlining would severely improve performance" which would indicate a bug
>>>> in the heuristics we can reliably detect and thus it wouldn't be there.
>>>
>>> I have interacted with users who are aware of optimizations such as
>>> inlining and unrolling and want to look at that information to
>>> diagnose performance differences when refactoring code or using a new
>>> compiler version. I also think inlining (especially cross-module) is
>>> one example of an optimization that is still being tuned, and user
>>> reports of performance issues related to that have been useful.
>>>
>>> I really think that the two groups of people who will find -fopt-info
>>> useful are gcc developers and savvy performance-hungry users. For the
>>> former group the additional info is extremely useful. For the latter
>>> group some of the extra information may not be required (although a
>>> call count is useful for those using profile feedback), but IMO is not
>>> unreasonable.
>>
>> well, your proposed output wrecks my 80x24 terminal already due to overly
>> long lines.
>>
>> In the end we may up with a verbosity level for each sub-set of opt-info
>> messages.  Ick.
>>
>> Richard.
>>
>>> Teresa
>>>
>>>
>>> --
>>> Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]