In order to minimize edit/compile/debug turn time, is there a way to compile llvm tools so that the majority of the files are compiled as if for release (eg, no debug symbols), and only the handful of files that I have touched are compiled for debugging? This will reduce the load on the file system, linker and gdb tremendously. At present, AFAICT, it’s all or nothing.
Nothing supported, though might not be too hard to do by hand.
If you’re having long link times, lots of disk usage, and slow gdb startup time I’d recommend enabling split DWARF (LLVM_USE_SPLIT_DWARF=ON, and CMAKE_EXE_LINKER_FLAGS_*=-Wl,-gdb-index in cmake) if you haven’t already.
Actually, I have same question, If llvm build provides a option similar to that, it will be lot more easier for people doing development in relatively less (compute, storage) PC’s.
Are you already using split DWARF & still having resource constraint problems? (oh, you could also compress debug info, -Wa,-compress-debug-sections)
Regarding resource constraint problems, I didn’t build llvm on much heavier machine previously, so it is difficult for me to tell whether my build is taking longer than expected trivially, fresh build (+ clang, lldb) takes time. But rebuild are actually fast.
I will use -compress-debug-sections with the full build and rebuilds and see how fast it is 
Making an assumption here: since debug-info is compressed, i think it may cause a overhead for the debugger. Is it true? If so, it overhead is observable to some extent ?
Regarding resource constraint problems, I didn’t build llvm on much heavier machine previously, so it is difficult for me to tell whether my build is taking longer than expected trivially, fresh build (+ clang, lldb) takes time. But rebuild are actually fast.
Are you already using split DWARF (& gdb-index)?
I will use -compress-debug-sections with the full build and rebuilds and see how fast it is
Making an assumption here: since debug-info is compressed, i think it may cause a overhead for the debugger. Is it true? If so, it overhead is observable to some extent ?
Compression will add some CPU compile time (& some link time, technically - since the linker will decompress the sections to link them), but might save time when writing fewer bytes to disk (& save disk usage). Similarly decompression by the debugger might slow things, but reading fewer bytes from disk may speed them up - will depend on the CPU versus disk IO speeds.
I used Split Dwarf, but actually in some builds only, I don’t know why I stopped using it. Thanks I will use them, and tell you how far it reduces the total time.
Yeah, understood that but I use llvm as shared libraries, which already costs me observable overhead while debugging. For what it’s worth, I will try my hands on it by compressing debug-info.
Clang has a way to achieve this. Once you’ve built LLVM without debug info, you can then delete the objects or modify the sources you want to debug and then rebuild with something like ‘CCC_OVERRIDE_OPTIONS=“±g ±O0” ninja’. The newly built files will have debug info.
Disclaimer I have only tested this while working on Clang, but I assume
it works for the entire LLVM project.
I have enabled shared libraries in CMake. Then I add the following lines
to the CMakeLists.txt, for example clang/lib/Parse/CMakeLists.txt
set_source_files_properties(
ParseDeclCXX.cpp
ParseDecl.cpp
Parser.cpp
ParseStmt.cpp
ParseExpr.cpp
ParseExprCXX.cpp
ParseInit.cpp
PROPERTIES
COMPILE_FLAGS "-O0 -g"
)
Then rebuild the clangParse target and have the debug symbols available.
Hope this helps.
Kind regards,
Mark de Wever
Since we are talking about a long link time and no one has mentioned about lld so far, I’d like to make sure that you are using lld, which is significantly faster than most other linkers.