On Thu, Mar 10, 2016 at 10:26 AM, René J.V. <rjvber...@gmail.com> wrote: > On Thursday March 10 2016 10:13:16 Jack Howarth wrote: > >> A simple test with 'sudo port -d -s build llvm-3.8' reveals that -Os >> is in fact used during the compiles on Intel. This is unsurprising as >> MacPorts has standardized on -Os. >> >> CFLAGS='-pipe -Os' >> CXXFLAGS='-pipe -Os -std=c++11 -stdlib=libc++' >> F90FLAGS='-pipe -Os -m64' >> FCFLAGS='-pipe -Os -m64' >> FFLAGS='-pipe -Os' >> OBJCFLAGS='-pipe -Os' >> OBJCXXFLAGS='-pipe -Os -stdlib=libc++' > > Did you look at the actual compile commands? Again, cmake is used, and when > you generate a makefile with CMAKE_BUILD_TYPE=Release it will *append* the > preset compiler options to whatever is fetched from CFLAGS, CXXFLAGS, etc. It > is my experience that setting -O3 in CFLAGS or CXXFLAGS has no point, because > those presets will override it with -O2 .
Of course I did... DEBUG: Executing command line: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build" && /opt/local/bin/cmake -DCMAKE_INSTALL_PREFIX=/opt/local -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON -DCMAKE_INSTALL_RPATH=/opt/local/lib -DCMAKE_INSTALL_NAME_DIR=/opt/local/lib -DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr" -DCMAKE_MODULE_PATH=/opt/local/share/cmake/Modules -DCMAKE_FIND_FRAMEWORK=LAST -Wno-dev -DLLVM_LINK_LLVM_DYLIB=ON -DCMAKE_INSTALL_PREFIX="/opt/local/libexec/llvm-3.8" -DLLVM_ENABLE_ASSERTIONS=OFF -DLLVM_ENABLE_RTTI=ON -DLLVM_INCLUDE_TESTS=OFF -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_ENABLE_FFI=ON -DLLVM_BINDINGS_LIST=none -DFFI_INCLUDE_DIR=/opt/local/include -DFFI_LIBRARY_DIR=/opt/local/lib -DCMAKE_C_FLAGS_RELEASE="-DNDEBUG" -DCMAKE_CXX_FLAGS_RELEASE="-DNDEBUG" -DCMAKE_OSX_ARCHITECTURES="x86_64" -DCMAKE_OSX_DEPLOYMENT_TARGET="10.11" -DCMAKE_OSX_SYSROOT="/" ../release_38 [ 0%] Building CXX object utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build/utils/TableGen && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build/utils/TableGen -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/release_38/utils/TableGen -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/release_38/include -pipe -Os -std=c++11 -stdlib=libc++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -std=c++11 -DNDEBUG -arch x86_64 -mmacosx-version-min=10.11 -fno-exceptions -o CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/release_38/utils/TableGen/AsmMatcherEmitter.cpp > > CMake does something similar for all 4 built-in presets, so the only way I > know to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a > custom value. Debian/Ubuntu do that in their packaging scripts > (-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that > uses -DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because CMake > doesn't have a dedicated variable for preprocessor options). > > Here's something much more interesting though: I just discovered that llvm > and clang 3.8 are both about TEN times smaller than they were in 3.6 and 3.7: > > /opt/local/var/macports/software/llvm-3.6: > total 158M > 158M -rw-r--r-- 1 bertin admin 158M Nov 15 19:10 > llvm-3.6-3.6.2_2.darwin_13.x86_64.txz > > /opt/local/var/macports/software/llvm-3.7: > total 188M > 188M -rw-r--r-- 1 bertin admin 188M Jan 9 21:11 > llvm-3.7-3.7.0_0.darwin_13.x86_64.txz > > /opt/local/var/macports/software/llvm-3.8: > total 15M > 15M -rw-r--r-- 1 bertin admin 15M Mar 10 16:08 > llvm-3.8-3.8-r262722_1.darwin_13.x86_64.txz > > /opt/local/var/macports/software/clang-3.6: > total 169M > 169M -rw-r--r-- 1 bertin admin 169M Nov 15 19:17 > clang-3.6-3.6.2_2+analyzer.darwin_13.x86_64.txz > > /opt/local/var/macports/software/clang-3.7: > total 182M > 182M -rw-r--r-- 1 bertin admin 182M Jan 9 21:34 > clang-3.7-3.7.0_2+analyzer.darwin_13.x86_64.txz > > /opt/local/var/macports/software/clang-3.8: > total 17M > 17M -rw-r--r-- 1 bertin admin 17M Mar 10 16:14 > clang-3.8-3.8-r262722_1+analyzer.darwin_13.x86_64.txz > > > What's going on here?? > > If that means that building from source also takes comparatively less time > and resources I might be inclined to experiment with non-shared builds, or a > build without RTTI support (even if that apparently should account for no > more than 5% performance loss). > > R _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
