This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new patches using -fopt-info (issue5294043)

On Sun, Oct 23, 2011 at 7:28 PM, Xinliang David Li <> wrote:
> On Sun, Oct 23, 2011 at 3:18 AM, Richard Guenther
> <> wrote:
>> On Fri, Oct 21, 2011 at 6:48 PM, Xinliang David Li <> 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

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


> 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
>>>>>>> --
>>>>>>> -- Speaking for myself only

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]