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

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 29 13:37:35 PDT 2019


Thanks for organizing the discussion and summarizing it. I haven't been
involved, but it all seems like it's going in the right direction.

On Tue, Oct 29, 2019 at 10:10 AM Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> There are also problems related to cross-runtime dependencies which have
> come up recently. Some of these problems can be addressed more cleanly with
> modern CMake generator expressions, and other issues may require a larger
> restructuring of code. For years there have been discussions thrown around
> about breaking the builtins libraries out of compiler-rt. Maybe now is the
> time to consider doing that.
>

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.

Here are the contents of compiler-rt/lib, with my categorizations:

Platform building blocks:
- crt
- builtins
- BlocksRuntime

Instrumentation tools:
- profile
- xray

Sanitizer or security things:
- cfi
- asan
- tsan
- ubsan
- ubsan_minimal
- dfsan
- fuzzer
- gwp_asan
- hwasan
- interception
- lsan
- msan
- safestack
- sanitizer_common
- stats
- scudo

---

All of the above said, I don't see any particularly strong reasons to
change anything at the moment, but maybe you have a good reason to separate
builtins and instrumentation that I haven't thought of.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191029/0be9f8ec/attachment.html>


More information about the llvm-dev mailing list