Except that in this form, the dump will be extremely large and not suitable for very large applications. 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.guent...@gmail.com> wrote: > 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
