[PATCH] D77346: [docs] Corrected inaccuracies in Common Problems section

[Adrian Prantl via Phabricator via llvm-commits]

aprantl added inline comments.


================
Comment at: llvm/docs/GettingStarted.rst:1109
+   Setting this option to lld will significantly reduce linking time for LLVM 
+   executables. If you are building LLVM for the first time and lld is not 
+   available to you as a binary package, then you may want to use the gold 
----------------
This text also does not apply to Darwin at all, where you would always want to use the system linker (until lld supports Mach-O).


================
Comment at: llvm/docs/GettingStarted.rst:1114
  * -DCMAKE_BUILD_TYPE
-   This option defaults to Debug; however, this may consume more memory during
-   the linking phase. So, you may wish to use the build type Release. 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. MinSizeRel is another build type you may wish to consider, if you
-   are still having problems with slow build time.
-
- * -DLLVM_PARALLEL_LINK_JOBS
-   Set this equal to number of jobs you wish to run simultaneously. This is
-   similar to the -j option used with make, but only for link jobs. This option
-   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.
+   This option defaults to Debug. On Linux, this causes higher memory usage 
+   during the linking phase. So, you may wish to use the Release build type and 
----------------
rnk wrote:
> aprantl wrote:
> > On platforms using ELF (such as Linux), this ...
> Actually, can I give the opposite feedback? I think adding platform specific admonitions can be confusing. Some day, someone will add an option to run dsymutil as a post-link step on Darwin, and then this statement will be true about Darwin as well as Linux. It is already true for Windows, whether using PDBs or DWARF.
> 
> Instead, would it be OK to soften it with `This *can* cause high memory usage during the linking phase.`, so that we can simplify away the condition?
You can already run dsymutil as a post-processing step using the LLVM_EXTERNALIZE_DEBUGINFO cmake option. That's how the clang that ships with Xcode is being built. But it still doesn't come with the same kind of memory explosion that you would get on ELF without split dwarf, since dsymutil (generally speaking) only processes one file at a time and performs type uniquing. I just want to avoid developers cargo-culting configuration options that make sense on one platform to another. On Darwin, the cost of building with debug info is negligible and I want to encourage new developers to use all the great tools we have available in the LLVM project. I don't want people to be afraid of using a debugger on LLVM.

So much for my rant ;-)

I think this text might also benefit from distinguishing between optimizations and debug info (Debug/Release/RelWithDebInfo) which are two axes unfortunately rolled into one CMake setting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77346