A build on `sparcv9-sun-solaris2.11` with `-DLLVM_ENABLE_PIC=Off` failed
linking `libRemarks.so`:
[27/2297] Linking CXX shared library lib/libRemarks.so.12git
FAILED: lib/libRemarks.so.12git
[...]
ld: fatal: relocation error: R_SPARC_H44: file lib/libLLVMRemarks.a(Remark.cpp.o): symbol _ZTVN4llvm18raw_string_ostreamE: invalid shared object relocation type: ABS44 code model unsupported
[...]
On Solaris/sparcv9 as on many other targets you cannot link non-PIC objects
into a shared object.
The following patch avoids this by not building the library with PIC. It
allowed the build to complete and `ninja check-all` showed no errors.
Differential Revision: https://reviews.llvm.org/D85626
This patch optionally replaces the CRT allocator (i.e., malloc and free) with rpmalloc (mixed public domain licence/MIT licence) or snmalloc (MIT licence) or mimalloc (MIT licence). Please note that the source code for these allocators must be available outside of LLVM's tree.
To enable, use `cmake ... -DLLVM_INTEGRATED_CRT_ALLOC=D:/git/rpmalloc -DLLVM_USE_CRT_RELEASE=MT` where `D:/git/rpmalloc` has already been git clone'd from `https://github.com/mjansson/rpmalloc`. The same applies to snmalloc and mimalloc.
When enabled, the allocator will be embeded (statically linked) into the LLVM tools & libraries. This currently only works with the static CRT (/MT), although using the dynamic CRT (/MD) could potentially work as well in the future.
When enabled, this changes the memory stack from:
new/delete -> MS VC++ CRT malloc/free -> HeapAlloc -> VirtualAlloc
to:
new/delete -> {rpmalloc|snmalloc|mimalloc} -> VirtualAlloc
The goal of this patch is to bypass the application's global heap - which is thread-safe thus inducing locking - and instead take advantage of a modern lock-free, thread cache, allocator. On a 6-core Xeon Skylake we observe a 2.5x decrease in execution time when linking a large scale application with LLD and ThinLTO (12 min 20 sec -> 5 min 34 sec), when all hardware threads are being used (using LLD's flag /opt:lldltojobs=all). On a dual 36-core Xeon Skylake with all hardware threads used, we observe a 24x decrease in execution time (1 h 2 min -> 2 min 38 sec) when linking a large application with LLD and ThinLTO. Clang build times also see a decrease in the range 5-10% depending on the configuration.
Differential Revision: https://reviews.llvm.org/D71786
Summary:
This will simplify the macros by allowing us to remove the hard-coded
list of libraries that should be installed when
LLVM_INSTALL_TOOLCHAIN_ONLY is enabled.
Reviewers: beanz, smeenai
Reviewed By: beanz
Subscribers: aheejin, mehdi_amini, mgorny, steven_wu, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D64580
llvm-svn: 365902
Getting rid of the name "optimization remarks" for anything that
involves handling remarks on the client side.
It's safer to do this now, before we get stuck with that name in all the
APIs and public interfaces we decide to export to users in the future.
This renames llvm/tools/opt-remarks to llvm/tools/remarks-shlib, and now
generates `libRemarks.dylib` instead of `libOptRemarks.dylib`.
Differential Revision: https://reviews.llvm.org/D58535
llvm-svn: 355439
