new patches using -fopt-info (issue5294043)
Xinliang David Li
Fri Oct 21 17:54:00 GMT 2011
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
> 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
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).
>>> So, please fix dump-files instead. And for coverage/profiling, fill
>>> in stuff in a dump-file!
>>>> 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.
>>>> firstname.lastname@example.org -- Speaking for myself only
More information about the Gcc-patches