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 Thu, Sep 14, 2017 at 11:55:21AM +0200, Richard Biener wrote:
> On Wed, Sep 13, 2017 at 5:08 PM, Allan Sandfeld Jensen
> <> wrote:
> > On Mittwoch, 13. September 2017 15:46:09 CEST Jakub Jelinek wrote:
> >> 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 default.
> >>
> > Would it be possible to enable basic block vectorization on -O2? I assume that
> > doesn't increase binary size since it doesn't unroll loops.
> Somebody needs to provide benchmarking looking at the compile-time cost
> vs. the runtime benefit and the code size effect.  There's also room to tune
> aggressiveness of BB vectorization as it currently allows for cases where
> the scalar computation is not fully replaced by vector code.

A good candidate too look at might be 525.x264_r from the SPEC2017 CPU
suite.  With just -O2, GCC is about 70% slower than LLVM (which I
think must be doing some vectorization at -O2).  When I give -O2
-ftree-vectorize to gcc, the difference drops to 20%, so vectorization
is not the whole story either.  There is no real difference in
run-time of executables generated with both compilers at -Ofast.

(But no, I'm not volunteering to analyze it further in foreseeable


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