This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Convert more passes to new dump framework
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Teresa Johnson <tejohnson at google dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Dehao Chen <dehao at google dot com>, Sharad Singhai <singhai at google dot com>, David Li <davidxl at google dot com>
- Date: Fri, 30 Aug 2013 10:30:48 +0200
- Subject: Re: [PATCH] Convert more passes to new dump framework
- Authentication-results: sourceware.org; auth=none
- References: <CAAe5K+W=brFLz3kZYFXTYAE+T2yJVPF=z+vp+uKh4d+9vQXJKQ at mail dot gmail dot com> <20130806123714 dot GD3166 at virgil dot suse> <CAAe5K+VSDkg5sKB2nvraHFv66ZKGO84W6obYj+sBfGZ7F3-hpw at mail dot gmail dot com> <20130806160102 dot GE3166 at virgil dot suse> <CAAe5K+VCwEUz1BWAnAvPrSBT3DHsu1P-eF4-nQb9+aFyDyRORw at mail dot gmail dot com> <CAAe5K+Vu0en=WFJp5bw-Vu=n05LYGxvmmfctnZSWeS-5PKT=Rg at mail dot gmail dot com> <CAFiYyc17odz-dL10BcNcKc8B_QNE2KB538dunz45=1Kn67d-gw at mail dot gmail dot com> <CAAe5K+W2rXph_7YkB1DgyXK55s4XQVtV+yvGY3q30-1DEkSK7A at mail dot gmail dot com> <CAFiYyc1DUmGZ1qeBL8mKRGy_1bd1whTW_XmmkOc-PU4WmGMoEg at mail dot gmail dot com> <CAAe5K+WBuaShbbA_hre_LK90NoShJ8yCRF0NLLnGcoQuZ6P-Nw at mail dot gmail dot com>
On Thu, Aug 29, 2013 at 5:15 PM, Teresa Johnson <firstname.lastname@example.org> wrote:
> On Thu, Aug 29, 2013 at 3:04 AM, Richard Biener
> <email@example.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  (99999000) inlined into foo  (1000)
>>>>> with call count 99999000 (via inline instance bar  (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
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
>> 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
well, your proposed output wrecks my 80x24 terminal already due to overly
In the end we may up with a verbosity level for each sub-set of opt-info
> Teresa Johnson | Software Engineer | firstname.lastname@example.org | 408-460-2413