On Thu, Aug 29, 2013 at 5:15 PM, Teresa Johnson <tejohn...@google.com> wrote: > On Thu, Aug 29, 2013 at 3:04 AM, Richard Biener > <richard.guent...@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 | tejohn...@google.com | 408-460-2413