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? The former is no different from any other informational notes we already have -- the only difference is that they are suppressed 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. > > 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. > > 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). 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 >>>> >>> >> >
