new patches using -fopt-info (issue5294043)

Xinliang David Li davidxl@google.com
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
opt-report.

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

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

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



More information about the Gcc-patches mailing list