This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: new patches using -fopt-info (issue5294043)
On Sun, Oct 23, 2011 at 7:28 PM, Xinliang David Li <davidxl@google.com> wrote:
> On Sun, Oct 23, 2011 at 3:18 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Fri, Oct 21, 2011 at 6:48 PM, Xinliang David Li <davidxl@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.
You say "no different from other informational notes" and I say we don't
have those at the moment. So it is different by means of that you are
going to ab-use informational notes.
>>
>>>>> ? ?..
>>>>> ?...
>>>>
>>>> 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.
Well, you seem to keep not reading what I write. I am not opposed
to adding -fopt-info/report nor to funnel messages to stdout/err. What
I am opposed is the way you want to introduce them. I want you to
fix what we dump into dump files, so that both -fopt-report and -fopt-info
can be implemented by outputting selected pieces of the dump file
to stdout/stderr. We already have -fdump-*-stats which supposedly
could match -fopt-report, and the default -fdump-* should be what
goes to -fopt-info (minus the function bodies, of course).
>>>
>>>>
>>>> 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, ...) ) ?
Well, design one that will work. But yes, a set of well-defined
dumping APIs, like
print_start_{loop,location,region,...} (...);
print_end_{loop...} (...);
or so.
> ? debug_print (message, dump_flags, message_verbose_level, ...)
Rather instead of verbosity levels use TDF_* flags (with maybe
reorganizing them a bit) internally, a verbosity level can be
implemented ontop of that by -fopt-{info,report} if needed.
> ? 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.
In the way? It is a prerequesite to both -fopt-info and -fopt-report.
Otherwise you will end up adding _additional_ dumping to passes.
Which is what I very very much object to. You can transition
to the common dump API incrementally and only handle the passes
you care for initially.
But anything else from a common mechanism isn't going to be
maintainable.
>>>>
>>>> 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).
Why at the end of compilation? Passes already collect info for
-stats dumping. What would -fopt-report print? Something like
note: I have reduced size of your binary by 90%
note: You should improve your programming skills
? Let's put -fopt-report aside for now as I don't have the slightest
idea what it should be.
> ? 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.
What scalability issue? I see a maintainance issue and a code
readability issue.
Richard.
> 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
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ak@linux.intel.com -- Speaking for myself only
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>