[llvm-dev] RFC: LLVM Build System Future Direction

[Chris Bieneman via llvm-dev]

> On Oct 29, 2019, at 1:50 PM, Martin Storsjö <martin at martin.st> wrote:
> 
> On Tue, 29 Oct 2019, Reid Kleckner via llvm-dev wrote:
> 
>> Why split out builtins from compiler-rt? They were the original compiler
>> runtime library. Should we go the other direction instead? For a long time,
>> I've wondered if we should have split the sanitizer runtimes out of
>> compiler-rt. GCC maintains a forked copy of some of the sanitizer runtimes
>> in a libsanitizer subdirectory next to libgcc:
>> https://github.com/gcc-mirror/gcc/tree/master/libsanitizer
>> I think we put the sanitizers in compiler-rt mainly because it is a
>> "compiler runtime", a runtime to which the compiler generates calls, but the
>> same applies to libcxxabi, OpenMP, I assume libcl, and other things. The
>> sanitizers are the biggest piece of compiler-rt by far, so maybe they
>> deserve their own top level directory.
> 
> When building a cross toolchain from scratch, with no preexisting libraries for the target, I end up building compiler-rt twice: First I build only the builtins, which are necessary for a basic working C environment. With builtins in place, I build libunwind/libcxxabi/libcxx, to get a working C++ environment. After that, I build compiler-rt again, building all of it, as the sanitizers now can be built as the C++ environment is complete.

This is the problem the llvm/runtimes directory seeks to solve. It builds the builtins separately from the rest of the runtimes, then builds everything else together.

> 
> (I haven't dug in very deep to see how much of a C++ standard library actually is required by the sanitizers, or if it's just a case where I could tell CMake to ignore the check for a "working" C++ compiler.)

My understanding is the sanitizers only require the c++ headers, not the library.

-Chris

> 
> // Martin
>