Consider building clang with DLLVM_ENABLE_PIC=OFF on Linux |
|
Issue description
I built clang twice, once with:
cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_TERMINFO=OFF -DLLVM_USE_CRT_RELEASE=MT -DCLANG_PLUGIN_SUPPORT=OFF -DLLVM_ENABLE_LIBXML2=FORCE_ON -DLLVM_ENABLE_THREADS=OFF -DLLVM_ENABLE_PIC=OFF ../llvm-rw/
ninja clang llvm-ar lld
and once with:
cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_TERMINFO=OFF -DLLVM_USE_CRT_RELEASE=MT -DCLANG_PLUGIN_SUPPORT=OFF -DLLVM_ENABLE_LIBXML2=FORCE_ON -DLLVM_ENABLE_THREADS=OFF ../llvm-rw/
ninja clang llvm-ar lld
The only difference is that the first has -DLLVM_ENABLE_PIC=OFF and the second doesn't. I checked that one build.ninja file passes -fPIC to Sema.cpp.o and the other doesn't.
I then built target 'base' in chrome three times (actually four times, but I discarded the first result as cache warmup) with
symbol_level = 1
is_component_build = true
is_debug = false
clang_base_path = getenv("HOME") + "/src/llvm-build-pic"
clang_use_chrome_plugins
by doing
thakis@thakis:~/src/chrome/src$ gn clean out/gn
thakis@thakis:~/src/chrome/src$ gn gen out/gn
Done. Made 12210 targets from 1873 files in 3059ms
thakis@thakis:~/src/chrome/src$ time ninja -C out/gn base
I got:
real 0m27.230s
user 13m24.791s
sys 0m32.916s
real 0m27.012s
user 13m26.341s
sys 0m32.099s
real 0m27.156s
user 13m25.614s
sys 0m32.425s
Then I did the same with
clang_base_path = getenv("HOME") + "/src/llvm-build-nopic"
and the rest the same. Here I got:
real 0m26.668s
user 13m19.867s
sys 0m32.466s
real 0m26.976s
user 13m20.559s
sys 0m32.160s
real 0m26.678s
user 13m19.674s
sys 0m32.012s
So it looks like this is in fact measuably faster, but the min-of-3 is only 1.27% faster. Still, it's basically free now that we build with the plugins compiled in. And the binary is 400kB smaller (again, not much, but free.)
(This was all on my linux desktop box. I think mac maybe always uses pic? not sure, need to check. LLVM's cmake file has some comment about -mdynamic-no-pic in Xcode, but that might be obsolete.)
,
Jan 15
I tried building packages with this, but r344241 made tests fail in that config. I left a comment on the thread for that revision.
,
Jan 16
(6 days ago)
,
Jan 16
(6 days ago)
,
Jan 16
(6 days ago)
those landed in 351373 , 351374
,
Jan 16
(6 days ago)
needs https://reviews.llvm.org/D56805 on mac
,
Jan 17
(5 days ago)
> I'm also not sure about macos. I seem to remember having heard that it requires position-independent executables, but I couldn't actually find anything to substantiate that when searching just now. Oh, but on mac we'll need to build a .dylib for LTO to be used by ld64? Sorry, I feel like this has been discussed before.
,
Jan 17
(5 days ago)
We don't use LTO on mac and don't build or bundle libLTO.dylib.
,
Jan 17
(5 days ago)
Right, but maybe we want to at some point? I always imagined the work towards ThinLTO on Windows would carry over to the rest of the platforms too. But I suppose we can deal with that when it's needed.
,
Jan 17
(5 days ago)
I don't think non-thin lto is viable for chrome, and I think ld64's libLTO.dylib plugin supports thin lto, so lto/mac is probably blocked on using new-style mach-o lld (if that ever happens).
,
Jan 17
(5 days ago)
Linux is green: https://chromium-review.googlesource.com/c/chromium/src/+/1412572 Probably want to do nice upstream fixes for mac and win even if we only want this for linux. https://reviews.llvm.org/D56805 fixes 3 of the 4 test failures on mac. Windows has link errors for c-index-test and arcmt-c-test.
,
Jan 17
(5 days ago)
Re #10: libLTO.dylib supports ThinLTO but not ThinLTO+CFI (or ThinLTO+devirtualization) which we might want eventually. Even just with regular LTO, in experiments I did about 4 years ago I had a lot of trouble trying to get the LTO plugin to work with Chromium which eventually revealed bugs on the ld64 side (e.g. http://www.openradar.me/20356002) which are still unfixed AFAIK. So if we did want LTO on Mac it would probably be best to invest in the new-style lld linker. |
|
►
Sign in to add a comment |
|
Comment 1 by h...@chromium.org
, Jan 14