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