Clang produces much larger binaries than GCC #21
Description
Since now GCC is deprecated and Clang is new default, we would like to see Clang building binaries that are of similar size (when using same optimisation parameters).
Currently, binaries produced by Clang are up to 15% larger than binaries produced by GCC.
Here are sizes of our barcode library when compiled with GCC 4.9 and when compiled with default Clang in r11 (both use gnustl_static as c++ library):
$ ls -lh libs_clang/*
libs_clang/arm64-v8a:
total 6616
-rwxr-xr-x 1 dodo staff 3.2M Mar 15 14:12 libBlinkBarcode.so
libs_clang/armeabi-v7a:
total 4904
-rwxr-xr-x 1 dodo staff 2.4M Mar 15 14:12 libBlinkBarcode.so
[dodo@mujcek: androidJni (feature/ndk-r11)]$ ls -lh libs_gcc/*
libs_gcc/arm64-v8a:
total 6096
-rwxr-xr-x 1 dodo staff 3.0M Mar 15 14:07 libBlinkBarcode.so
libs_gcc/armeabi-v7a:
total 4304
-rwxr-xr-x 1 dodo staff 2.1M Mar 15 14:07 libBlinkBarcode.so
Can this be looked into in r11b or in r12?
Compile options used for Clang (armeabi-v7a target):
-fpic -ffunction-sections -funwind-tables -fstack-protector-strong -Wno-invalid-command-line-argument -Wno-unused-command-line-argument -no-canonical-prefixes -fno-integrated-as -target armv7-none-linux-androideabi -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -fno-exceptions -fno-rtti -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -mfpu=neon -Wno-parentheses-equality -Wno-invalid-command-line-argument -Wno-unused-command-line-argument -Qunused-arguments -Wno-unknown-warning-option -Wno-psabi -Wno-unknown-pragmas -Werror -Wno-error=deprecated-declarations -Wno-error=cpp -Wall -Os -Wconversion -Wno-sign-conversion -Wno-write-strings -Wno-pragmas -Wvla -Wformat-security -Wextra -Wno-unused-parameter -Wno-ignored-qualifiers -Wno-type-limits -fvisibility=hidden -ffunction-sections -fstack-protector-all -Wa,--noexecstack -Wformat -Werror=format-security -std=c++11 -Wno-overloaded-virtual -fvisibility-inlines-hidden -fexceptions
and GCC (armeabi-v7a target - some warning flags are different or missing because those are not supported under GCC):
-fpic -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -fno-exceptions -fno-rtti -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -mfpu=neon -Wno-psabi -Wno-unknown-pragmas -Werror -Wno-error=deprecated-declarations -Wno-error=cpp -Wall -Os -Wconversion -Wno-sign-conversion -Wno-write-strings -Wno-pragmas -Wvla -Wformat-security -Wextra -Wno-unused-parameter -Wno-ignored-qualifiers -Wno-type-limits -fvisibility=hidden -ffunction-sections -fstack-protector-all -Wa,--noexecstack -Wformat -Werror=format-security -std=c++11 -Wno-overloaded-virtual -fvisibility-inlines-hidden -fexceptions
Generally, you can see that both Clang and GCC use -Os optimisation flag.
If achieving the same binary size as with GCC is not possible, we would like at least then better performance of binary produced by Clang. We need to somehow explain to our clients why our library will be 15% larger when we start using Clang.