[llvm-dev] [RFC] Strategies for Bootstrapping Compiler-RT builtins

[Steve King via llvm-dev]

Hi Chris - Many thanks for airing all this.   I'm now hopeful for an
end to my own hacks and false starts trying to fix these same
problems.  My response is coming from the perspective of an
out-of-tree target without binutils or libgcc support.

On Mon, Nov 2, 2015 at 9:10 AM, Chris Bieneman via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> (3) Split the built-ins and the runtime libraries

+1.  Eliminating unnecessary entanglement is good engineering and
helps especially in the overwhelming early days of new target
development.

> I believe that the cleanest solution to this problem is going to be to separate the built-ins and the sanitizers.

+1, again for sensible modularity and being merciful on new targets.

> Logistically this solution could take many forms. We could break compiler-rt out into two repositories, which would be a huge undertaking, or we could leave it as a single repository and have the built-ins be able to build as a sub-project. I think we can make it work such that compiler-rt can be built either from the top-level directory to build it all, or from the built-ins sub directory to support bootstrapping cross-compilers.

I'm not sure if this jibes with your statement, but IMHO, the
refactored built-ins should move into the LLVM repo.  In this spirit,
I believe gcc includes libgcc in-tree.  Being both a small library and
intimately tied to LLVM, the complexity of a new separate built-ins
repo is a little dubious.  The sanitizers are a separate can of worms.

Thanks,
-steve