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)

Richard, Thanks for the comments.

Let me give some background of the patch: The initial intention of the
patch is to suppress
the verbose warnings and notes emitted in profile-use compilation.
This warnings/notes are caused
by inconsistent profile due to data race (which is currently common in
multi-thread programs),
and some stale profiles (after adding a new functions). While valid,
they can easily pollute the build log.
In addition, some of these warnings cannot be disabled by any options
except -Wno-error. We have
many FDO users and these verbose messages one of the most complained issues.

The first patch was adding another option to control the fdo related
messages. Later we thought it's
better to do this in more general way. And here comes this patch.

I believe fopt-info is very useful for tracking regressions for
certain important optimization (inline, loop opt etc).
IR dump is just too big and add too much overhead to compilation (look
how many files it creates).


On Thu, Oct 20, 2011 at 1:21 AM, Richard Guenther
<> wrote:
> On Thu, Oct 20, 2011 at 1:33 AM, Andi Kleen <> wrote:
>> (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.
> I think =2 and =3 should be omitted - we do have dump-files for a reason.
> 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).
> 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]
> 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]