On Mon, Oct 24, 2011 at 6:27 PM, Xinliang David Li <davi...@google.com> wrote:
>> 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).
>
> That sounds good. What you propose seems like
>
> -fdump-pass-[ir_only|transformation|debug]-stderr
>
> and -fopt-info is a short cut for
> -fdump-tree-all-transformations-stderr
> -fdump-ipa-all-tranformations-stderr
> -fdump-rtl-all-transformations-stderr
Yes. Note that I don't like it the way the vectorizer does (with
-fvectorizer-verbose=... the dump files are empty). The dump
file content should be unchanged when redirecting (parts) to
stderr, so we have to arrange to duplicate messages in two places.
Richard.
>
> thanks,
>
> David
>
>
>
>>
>>>>>
>>>>>>
>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> a...@linux.intel.com -- Speaking for myself only
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
