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

> 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

>
> Sure. I’m not sure if everyone will agree with me, but my general
> assertion is that if you’re doing a full bootstrap of a cross compiler,
> we’re not going to fully support that from a single CMake build tree. We
> didn’t support that in autoconf, so I don’t think CMake should be different
> in that regard. I envision bootstrapping a full cross-platform to be
> something like:
> (1) build in-tree clang
> (2) build out-of-tree builtin library
> (3) build out-of-tree runtime libraries

This seems reasonable to me.
The default int-tree stuff should be for the host.
I don't think many will have issue with doing out of tree builds or the
builtins or the runtime if they are cross compiling.

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.
Not quite sure why IOS is built by default on darwin it should probably be
OSX only and out of tree for IOS like you said above.
Doubt many will agree with changing this now though.
> 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.

Yes Darwin seems to be the biggest blocker here with the least amount of
work gone into it.
The COFF and ELF linkers have been replaced with section based ones as that
makes more sense.
I don't know enough about MachO to say if would be better with switching or
staying with an atom based design.
It would be great if maybe an apple engineer more in the know would
nominate them selves and bring it up to par with the rest and then maybe become
an OWNER.

On other platforms I think there are still places that lld isn’t
fully
> fleshed.
Yes there are some parts still missing and that are wip but the new COFF
and ELF section based linkers should bootstrap just fine.

Just as a point for building the builtins shouldn't we just need llvm-ar ?
While not being feasible for the Darwin target as you said above it should
be perfectly fine for windows and linux.
I don't think we should even need the linker to bootstrap the builtins or
am I incorrect in saying this ?
If so I think it think it would be reasonable to have that as the mission
creep.

On Tue, Nov 3, 2015 at 12:03 AM, Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> > 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/bd77d3b9/attachment.html>

> On Nov 3, 2015, at 6:33 AM, Martell Malone <martellmalone at
gmail.com> wrote:
> 
> Sure. I’m not sure if everyone will agree with me, but my general assertion
is that if you’re doing a full bootstrap of a cross compiler, we’re not going to
fully support that from a single CMake build tree. We didn’t support that in
autoconf, so I don’t think CMake should be different in that regard. I envision
bootstrapping a full cross-platform to be something like:
> (1) build in-tree clang
> (2) build out-of-tree builtin library
> (3) build out-of-tree runtime libraries
> 
> This seems reasonable to me.
> The default int-tree stuff should be for the host.
> I don't think many will have issue with doing out of tree builds or the
builtins or the runtime if they are cross compiling.
Cool. This then makes your other point about requiring LLVM tools less of an
issue because the out-of-tree builds can use whatever tools you choose. We just
need to make the builtins work so that you don’t need them already built.
> 
> 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.
> Not quite sure why IOS is built by default on darwin it should probably be
OSX only and out of tree for IOS like you said above.
> Doubt many will agree with changing this now though.
I’m the one who landed a lot of that code, and I want to rip it all out. We just
need to make it work the right way before we can rip it out.
> 
> > 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.
> 
> Yes Darwin seems to be the biggest blocker here with the least amount of
work gone into it.
> The COFF and ELF linkers have been replaced with section based ones as that
makes more sense.
> I don't know enough about MachO to say if would be better with
switching or staying with an atom based design.
Not to re-hash an old argument, but Apple has no interest in a section-based
MachO linker. We already have a great one of those that doesn’t have the
licensing issues that come with binutils. What we do want is a better optimizing
linker, which is what is leading us to support the atom-based design.
> It would be great if maybe an apple engineer more in the know would
nominate them selves and bring it up to par with the rest and then maybe become
an OWNER.
Lang has been putting a lot of work into that, and he did nominate himself as
code owner, it is even reflected in the CODE_OWNERS list. The only parts of LLVM
that I think don’t build correctly with LLD on MachO are some of the runtime
libraries, but I expect that will get fleshed out soon enough too.
> 
> On other platforms I think there are still places that lld isn’t fully
fleshed.
> Yes there are some parts still missing and that are wip but the new COFF
and ELF section based linkers should bootstrap just fine.
> 
> Just as a point for building the builtins shouldn't we just need
llvm-ar ?
> While not being feasible for the Darwin target as you said above it should
be perfectly fine for windows and linux.
> I don't think we should even need the linker to bootstrap the builtins
or am I incorrect in saying this ?
> If so I think it think it would be reasonable to have that as the mission
creep.
I think that since bootstrapping will be an out-of-tree build there is no reason
to require a fully LLVM toolchain as it doesn’t get us anything. Once we make
the builtins work just requiring a compiler, ar, and ranlib there is nothing
stopping anyone from bootstrapping with a fully LLVM toolchain on Linux.

-Chris
> 
> On Tue, Nov 3, 2015 at 12:03 AM, Chris Bieneman via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
> > On Nov 2, 2015, at 2:44 PM, Steve King <steve at metrokings.com
<mailto:steve at metrokings.com>> wrote:
> >
> > On Mon, Nov 2, 2015 at 1:02 PM, Chris Bieneman <beanz at apple.com
<mailto: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
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/8bc1fa87/attachment.html>

On Tue, Nov 3, 2015 at 6:33 AM, Martell Malone <martellmalone at
gmail.com> wrote:
> Just as a point for building the builtins shouldn't we just need
llvm-ar ?
Thanks for pointing this out and I hope llvm-ar is up to the task.
Even if targets must still port binutils, each step toward LLVM
self-reliance is a step in the right direction.

Without getting too far ahead of ourselves, refactoring built-ins into
a distinct library is a great place to start.