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: RFC: Improving GCC8 default option settings

On September 13, 2017 5:35:11 PM GMT+02:00, Jan Hubicka <> wrote:
>> On Wed, Sep 13, 2017 at 3:46 PM, Jakub Jelinek <>
>> > On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
>> >> On its own -O3 doesn't add much (some loop opts and slightly more
>> >> aggressive inlining/unrolling), so whatever it does we
>> >> should consider doing at -O2 eventually.
>> >
>> > Well, -O3 adds vectorization, which we don't enable at -O2 by
>> As said, -fprofile-use enables it so -O2 should eventually do the
>> for "really hot code".
>I don't see static profile prediction to be very useful here to find
>hot code" - neither in current implementation or future. The problem of
>-O2 is that we kind of know that only 10% of code somewhere matters for
>performance but we have no way to reliably identify it.

It's hard to do better than statically look at (ipa) loop depth. But shouldn't that be good enough? 

>I would make sense to have less agressive vectoriazaoitn at -O2 and
>more at

We tried that but the runtime effects were not offsetting the compile time cost. 

>Adding -Os and -Oz would make sense to me - even with hot/cold info it
>is not
>desriable to optimize as agressively for size as we do becuase mistakes
>and one do not want to make code paths 1000 times slower to save one
>of binary.
>We could handle this gratefully internally by having logic for "known
>to be cold"
>and "guessed to be cold". New profile code can make difference in this.
>> Richard.
>> >         Jakub

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