[LLVMdev] Compiler-RT roadmap

[David Chisnall]

On 13 Feb 2014, at 09:46, Iain Sandoe <iain at codesourcery.com> wrote:

> However, I still think it's necessary to make inclusion of the unwinder (in a given build) optional, or to allow it to be built as a separate module, since on many systems clang/llvm is an add-on compiler where we might want to use the code-fragments in "llvm-rt" in conjunction with an external unwinder which is part of an existing system.

On these systems, I'd imagine that we'd also most likely use the implementations of a number of builtins from whatever the system provided.

I don't really see the compiler-rt code as something that I'd expect people to build as-is.  Both FreeBSD and Apple pull code from there, but neither of us use the upstream build system.  In OS X I think they mostly go into libSystem.dylib, in FreeBSD they go into libgcc and friends (these are increasingly llvm code and not gcc code, but the names are retained for historical reasons.  Eventually we'll probably turn /lib/libgcc_s.so.1 into a symlink to something else).  

I guess there are three use cases for the compiler-rt code:

- You're producing a completely stand-alone development environment for an OS (e.g. something like MinGW) and you need to have all of the support functions, so you build compiler-rt and you link it into your programs.

- You're building on a system that provides support libraries but doesn't implement everything that your LLVM-based compiler needs, so you take parts of compiler-rt to fill in the gaps.

- You're building the core libraries for an OS, so you take the code and put it wherever makes the most sense for your architecture.

I think that having the unwind code as a separate library under compiler-rt helps all of these cases, so I'm definitely not opposed to that.  I wonder if we need to go further and make more symbols weak so that they can be replaced more easily.

David