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

[Teresa Johnson <tejohnson at google dot com>]

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'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.

Teresa


-- 
Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413