On Sun, Oct 23, 2011 at 3:18 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Fri, Oct 21, 2011 at 6:48 PM, Xinliang David Li <davi...@google.com> wrote: >> There are two proposals here. One is -fopt-info which prints out >> informational notes to stderr, and the other is -fopt-report which is >> more elaborate form of dump files. Are you object to both or just the >> opt-report one? > > What? I'm objected to adding _two_ variants. Didn't even realize > you proposed that.
They are different -- -fopt-info is on the fly -- the notes are emitted as the transformations are done while -fopt-report is for more structured report so it requires more compiler changes. Bringing in -fopt-report is a little distraction as the main discussion is on -fopt-info. > >> The former is no different from any other >> informational notes we already have -- the only difference is that >> they are suppressed by default. > > We do not have many informational notes, so it is different. Why different? opt information notes are not even emitted by default. > >>>> .. >>>> ... >>> >>> I very well understand the intent. But I disagree with where you start >>> to implement this. Dump files are _not_ only for developers - after >>> all we don't have anything else. -fopt-report can get as big and >>> unmanagable >>> to read as dump files - in fact I argue it will be worse than dump files if >>> you go beyond very very coarse reporting. >> >> The problem of using dump files for optimization report is that all >> optimization decisions are 'distributed' in phase specific dumps file. >> For a whole program report, the number of files that are created is >> not manageable (think about a program with 4000 sources each dumping >> 200 files). If we create a dummy pass and suck in all optimization >> decisions in that pass's dump file -- it will be no different from >> opt-report. > > Well, -fopt-whatever will just funnel selected pieces also to stderr. > I object to duplicate dumping when we just need a way to filter > what goes to dump files. > that is the main point -- using dump files are not scalable. If you are just against using stderr and propose dumping the selected information into a single shared dump file per build, I don't see the difference with using stderr -- they are not emitted by default and won't contaminate the build log. >> >>> >>> Yes, dump files are a "mess". So - why not clean them up, and at the >>> same time annotate dump file pieces so _automatic_ filtering and >>> redirecting to stdout with something like -fopt-report would do something >>> sensible? I don't see why dump files have to stay messy while you at >>> the same time would need to add _new_ code to dump to stdout for >>> -fopt-report. >> >> In my mind, I would like to separate all dumps into three categories. >> >> 1) IR dumps, and support dump before and after (this reminds me my >> patches are still pending :) ) -fdump-tree-pre-[before|after]-.... >> Dump into .after, .before files >> 2) debug tracing etc: -fdump-tree-pre-debug-... Dump >> into .debug files. >> 3) opt report : -fdump-opt or -fopt-report >> >> Changes for 1) and 2) are mechanic but requires lots of work. > > You can do that, but I want the passes to use a single mechanism to > feed all three "separated dumps". > Can you elaborate on single mechanism here? A set of well defined dumping APIs (instead of free form of if (dump_file) fprintf (dump_file, ...) ) ? debug_print (message, dump_flags, message_verbose_level, ...) trace_enter (trace_header_note) trace_exit (trace_header_not) opt_info_print (location, message_template, insertion) Or how dump files are organized? I am all for clean up of dumping, but I don't see how -fopt-info get in the way of that. >>> >>> So, no, please do it the right way that benefits both compiler developers >>> and your "power users". >>> >>> And yes, the right way is not to start adding that -fopt-report switch. >>> The right way is to make dump-files consumable by mere mortals first. >> >> I agree we need to do the right way which needs to be discussed first. >> I would argue that mere mortals will really appreciate opt-info >> (separate from dump file and opt-report). > > Well, still what you print with opt-info should be better also be present > with opt-report and in dump files. Thus it all boils down to be able > to filter what passes put in their dump files. opt-report is different (needs to buffer information and dumping at the end of compilation). Dump files and fopt-info can share the same dumping format -- whatever gets emitted by opt-info should also be emitted in the dump file (or replace the less well formated transformation messages that are already available in dump files), however simply filering the dump info does not solve the scalabilty issue I mentioned. thanks, David > > Richard. > >> thanks, >> >> David >> >>> >>> Thanks, >>> Richard. >>> >>>> >>>> Thanks, >>>> >>>> David >>>> >>>>> >>>>> So, please fix dump-files instead. And for coverage/profiling, fill >>>>> in stuff in a dump-file! >>>>> >>>>> Richard. >>>>> >>>>>> It would be interested to have some warnings about missing SRA >>>>>> opportunities in =1 or =2. I found that sometimes fixing those can give a >>>>>> large speedup. >>>>>> >>>>>> Right now a common case that prevents SRA on structure field >>>>>> is simply a memset or memcpy. >>>>>> >>>>>> -Andi >>>>>> >>>>>> >>>>>> -- >>>>>> a...@linux.intel.com -- Speaking for myself only >>>>>> >>>>> >>>> >>> >> >
