On Fri, Aug 30, 2013 at 6:27 PM, Xinliang David Li <davi...@google.com> wrote: > Except that in this form, the dump will be extremely large and not > suitable for very large applications.
So? You asked for it and you can easily grep the output before storing it away. > 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
