New issue
Advanced search Search tips

Issue 920687 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug

Blocked on:
issue 917404

Blocking:
issue 903751



Sign in to add a comment

Consider building clang with DLLVM_ENABLE_PIC=OFF on Linux

Project Member Reported by thakis@chromium.org, Jan 10

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.)
 
Thanks for investigating this! Sounds like there's basically no cost and a measurable gain, so let's do it.

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.
I tried building packages with this, but r344241 made tests fail in that config. I left a comment on the thread for that revision.

Comment 3 by thakis@google.com, Jan 16 (6 days ago)

Comment 4 by thakis@google.com, Jan 16 (6 days ago)

Comment 5 by thakis@google.com, Jan 16 (6 days ago)

those landed in 351373 , 351374

Comment 6 by thakis@google.com, Jan 16 (6 days ago)

needs https://reviews.llvm.org/D56805 on mac

Comment 7 by h...@chromium.org, 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.

Comment 8 by thakis@google.com, Jan 17 (5 days ago)

We don't use LTO on mac and don't build or bundle libLTO.dylib.

Comment 9 by h...@chromium.org, 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.

Comment 10 by thakis@google.com, 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).

Comment 11 by thakis@chromium.org, 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.

Comment 12 by p...@chromium.org, 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