On Wed, Sep 13, 2017 at 09:27:22AM +1200, Michael Clark wrote:
> > Other compilers enable more optimizations at -O2 (loop unrolling in LLVM was
> > mentioned repeatedly) which GCC could/should do as well.
>
> There are some nuances to -O2. Please consider -O2 users who wish use it like
> Clang/LLVM’s -Os (-O2 without loop vectorisation IIRC).
>
> Clang/LLVM has an -Os that is like -O2 so adding optimisations that increase
> code size can be skipped from -Os without drastically effecting performance.
>
> This is not the case with GCC where -Os is a size at all costs optimisation
> mode. GCC users option for size not at the expense of speed is to use -O2.
"Size not at the expense of speed" exists in neither compiler. Just the
tradeoffs are different between GCC and LLVM. It would be a silly
optimisation target -- it's exactly the same as just "speed"! Unless
"speed" means "let's make it faster, and bigger just because" ;-)
GCC's -Os is not "size at all costs" either; there are many options (mostly
--params) that can decrease code size significantly. To tune code size
down for your particular program you have to play with options a bit. This
shouldn't be news to anyone.
'-Os'
Optimize for size. '-Os' enables all '-O2' optimizations that do
not typically increase code size. It also performs further
optimizations designed to reduce code size.
> So if adding optimisations to -O2 that increase code size, please considering
> adding an -O2s that maintains the compact code size of -O2. -O2 generates
> pretty compact code as many performance optimisations tend to reduce code
> size, or otherwise add optimisations that increase code size to -O3. Adding
> loop unrolling on makes sense in the Clang/LLVM context where they have a
> compact code model with good performance i.e. -Os. In GCC this is -O2.
>
> So if you want to enable more optimisations at -O2, please copy -O2
> optimisations to -O2s or rename -Os to -Oz and copy -O2 optimisation defaults
> to a new -Os.
'-O2'
Optimize even more. GCC performs nearly all supported
optimizations that do not involve a space-speed tradeoff. As
compared to '-O', this option increases both compilation time and
the performance of the generated code.
> The present reality is that any project that wishes to optimize for size at
> all costs will need to run a configure test for -Oz, and then fall back to
> -Os, given the current disparity between Clang/LLVM and GCC flags here.
The present reality is that any project that wishes to support both GCC and
LLVM needs to do configure tests, because LLVM chose to do many things
differently (sometimes unavoidably). If GCC would change some options
to be more like LLVM, all users only ever using GCC would be affected,
while all other incompatibilities would remain. Not a good tradeoff at
all.
Segher
