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 Thu, Oct 20, 2011 at 1:21 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Thu, Oct 20, 2011 at 1:33 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> xur@google.com (Rong Xu) writes:
>>
>>> After some off-line discussion, we decided to use a more general approach
>>> to control the printing of optimization messages/warnings. We will
>>> introduce a new option -fopt-info:
>>> ?* fopt-info=0 or fno-opt-info: no message will be emitted.
>>> ?* fopt-info or fopt-info=1: emit important warnings and optimization
>>> ? ?messages with large performance impact.
>>> ?* fopt-info=2: warnings and optimization messages targeting power users.
>>> ?* fopt-info=3: informational messages for compiler developers.
>
> This doesn't look scalable if you consider that each pass would print
> as much of a mess like -fvectorizer-verbose=5.
What is not scalable? For level 1 dump, only the summary of
vectorization will be printed just like other loop transformations.
>
> I think =2 and =3 should be omitted - we do have dump-files for a reason.
Dump files are not easy to use -- it is big, and slow especially for
people with large distributed build systems. Having both level 2 and
3 is debatable, but it will be useful to have a least one level above
level 1. Dump files are mainly for compiler developers, while
-fopt-info are for compiler developers *and* power users who know
performance tuning.
>
> Also the coverage/profile cases you changed do not at all match
> "... with large performance impact". ?In fact the impact is completely
> unknown (as it would be the case usually).
Impact of any transformations is just 'potential', coverage problems
are no different from that.
>
> I'd rather have a way to make dump-files more structured (so, following
> some standard reporting scheme) than introducing yet another way
> of output. ?[after making dump-files more consistent it will be easy
> to revisit patches like this, there would be a natural general central
> way to implement it]
Yes, I remember we have discussed about this before -- currently dump
files are a big mess -- debug tracing, IR are all mixed up, but as I
said above, this is a different matter -- it is for compiler
developers.
For more structured optimization report, we should use option
-fopt-report which dump optimization information based on category --
the info data base can also be shared across modules:
Example:
[Loop Interchange]
File a, line x, yyyyyyy
File b, line xx, yyyyyyy
....
File c, line z, It is beneficial to interchange the loop, but not
done because of possible carried dependency (caused by false aliasing
...)
[Loop Vectorization]
....
[Loop Unroll]
...
[SRA]
[Alias summary]
[Global Vars]
a: addr exposed
b: add not exposed
..
[Global Pointers]
..
...
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
>>
>