[PATCH] D75425: [docs] Added solutions to slow build under common problems

[Nico Weber via Phabricator via llvm-commits]

thakis added a comment.

Thanks for doing this!

I spend a lot of time with llvm's build, so here are some more comments.



================
Comment at: llvm/docs/GettingStarted.rst:1114-1119
+ * -DCMAKE_BUILD_TYPE  
+   Set this equal to the build you wish to use, either Debug or Release. The 
+   Debug build may consume more memory during the linking phase. Another build 
+   type you may wish to consider is release-with-asserts which compiles at 
+   nearly the same rate as the Release build; however, it may not be as easy
+   to debug.
----------------
Meinersbur wrote:
> Actually, LLVM defaults to `CMAKE_BUILD_TYPE=Debug` in its CMakeLists.txt:
> ```
> if (NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
>   message(STATUS "No build type selected, default to Debug")
>   set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "Build type (default Debug)" FORCE)
> endif()
> ```
> This is is not generally true for CMake projects, so as a rule of thumb, I personally always define CMAKE_BUILD_TYPE.
> 
> For the documentation, we should make aware of `CMAKE_BUILD_TYPE=Release` (or maybe even MinSizeRel) in contrast to the default `Debug`. Consider switching `LLVM_ENABLE_ASSERTIONS=ON` for release builds. It is off by default for non-debug builds.
Looks like this got lost. I agree that release builds with LLVM_ENABLE_ASSERTIONS=ON is a good build config, so it makes sense to mention both.


================
Comment at: llvm/docs/GettingStarted.rst:1127-1128
+   is of course only meaningful if you plan to build with ninja. You may wish to 
+   use a very low number of jobs, as this will greatly reduce the amount memory 
+   used during the build process. If you have limited memory, you may wish to 
+   set this to 1.
----------------
Meinersbur wrote:
> lebedev.ri wrote:
> > Since lld is internally parallel, i'd even say this should always be 1 if using lld.
> If this is true, our CMakeLists.txt should set `LLVM_PARALLEL_LINK_JOBS` whenever `LLVM_USE_LINKER` is set to lld.
lld doesn't use that much parallelism, and lld jobs don't run that long. I don't think this should default to 1 with lld (if you hand benchmarks that show it's useful that changes things of course, but that'd surprise me).


================
Comment at: llvm/docs/GettingStarted.rst:1110
+   performance. In the case that you are compiling lld, you may wish to use the
+   gold linker as a faster alternative.
+
----------------
This is misleading. You should always use lld, even when working on lld. Lld is faster at linking lld than gold is. This should recommend lld over gold more strongly, and possibly not mention gold at all -- I'm aware of no reason to use gold (except possibly if you're on a mips box).


================
Comment at: llvm/docs/GettingStarted.rst:1120
+
+ * -DLLVM_PARALLEL_LINK_JOBS
+   Set this equal to number of jobs you wish to run simultaneously. This is
----------------
Do you have numbers to back this up? At least for release builds, I haven't seen speedup from this (when using lld to link), on systems with as little as 16 gb if memory.


================
Comment at: llvm/docs/GettingStarted.rst:1134
+ * -DLLVM_OPTIMIZED_TABLEGEN
+   Set this to ON to generate a fully optimized tablegen during build. This will
+   significantly improve your build time.
----------------
I believe this is only useful if you're doing debug builds, which you already advise against.


================
Comment at: llvm/docs/GettingStarted.rst:1144
+   Set this option to OFF if you do not require the clang static analyzer. This
+   should improve your build time significantly.
+
----------------
"significantly" oversells this; it reduced full build time of clang by ~5% last I checked.


================
Comment at: llvm/docs/GettingStarted.rst:1147
+ * -DLLVM_USE_SPLIT_DWARF
+   Consider setting this to ON if you require a debug build, as this will ease
+   memory pressure on the linker. This will make linking much faster, as the
----------------
Maybe mention that this one is Linux only.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75425/new/

https://reviews.llvm.org/D75425