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. > 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. >>> .. >>> ... >> >> 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. > >> >> 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". >> >> 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. 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 >>>>> >>>> >>> >> >
