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

> On Nov 2, 2015, at 12:01 PM, Steve King <steve at metrokings.com>
wrote:
> 
> 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.
Sadly, I believe there are licensing reasons why the builtins can’t be in the
LLVM repo. Specifically the LLVM license has an attribution clause that the
compiler-rt license deliberately doesn’t have. The LLVM attribution clause if
applied to the builtins would mean anyone who builds an application that links
the builtins would need to distribute their software with a notice saying it
includes LLVM code.

-Chris
> 
> Thanks,
> -steve

On Mon, Nov 2, 2015 at 1:02 PM, Chris Bieneman <beanz at apple.com>
wrote:
> Sadly, I believe there are licensing reasons why the builtins can’t be in
the LLVM repo.
Repos and licenses are orthogonal, but I get the concern.

Switching gears to other questions:
Should the bootstrap build automatically produce a built-ins library
for each target in "llvm-config --targets-built" or is the developer
expected to provide an explicit list?  Hopefully the former.

Is it reasonable that bootstrap build not depend on GNU binutils?
This might be mission creep, but it's a drag that the unspoken first
step in developing an LLVM based toolchain is "port binutils".  I
haven't kept watch on LLD progress, but perhaps it's far enough along
that bootstrap process can depend on it.

Regards,
-steve

> On Nov 2, 2015, at 2:44 PM, Steve King <steve at metrokings.com>
wrote:
> 
> On Mon, Nov 2, 2015 at 1:02 PM, Chris Bieneman <beanz at apple.com>
wrote:
>> Sadly, I believe there are licensing reasons why the builtins can’t be
in the LLVM repo.
> 
> Repos and licenses are orthogonal, but I get the concern.
> 
> Switching gears to other questions:
> Should the bootstrap build automatically produce a built-ins library
> for each target in "llvm-config --targets-built" or is the
developer
> expected to provide an explicit list?  Hopefully the former.
Today there isn’t really a simple answer. For Linux I think the bootstrap only
builds for the host architecture by default. For Darwin, it builds all supported
Darwin architectures, which can be complicated to determine.
> 
> Is it reasonable that bootstrap build not depend on GNU binutils?
Not necessarily. To my understanding LLVM doesn’t fully replace bin utils on any
platform yet, and I think we’re a long way from saying the LLVM toolchain is the
default builtin toolchain.
> This might be mission creep, but it's a drag that the unspoken first
> step in developing an LLVM based toolchain is "port binutils".  I
> haven't kept watch on LLD progress, but perhaps it's far enough
along
> that bootstrap process can depend on it.
On Darwin ar and lld are the biggest pieces that aren’t fully featured yet. On
other platforms I think there are still places that lld isn’t fully fleshed.

-Chris
> 
> Regards,
> -steve