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

[Richard Biener <richard dot guenther at gmail dot com>]

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