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

>
> I will not be stripping out any of the existing CMake. If we go down this
> path what I’m going to do is refactor the CMake to produce to logically
> separated projects so that the builtins can be built with or without the
> runtime libraries. It will all still be CMake-based.
Sorry. s/stripping/seperating/g
I was still thinking about the stripping of the IOS build from the OSX
default build :)

On Tue, Nov 3, 2015 at 6:30 PM, Chris Bieneman <beanz at apple.com> wrote:
>
> On Nov 3, 2015, at 9:24 AM, Martell Malone <martellmalone at
gmail.com>
> wrote:
>
> 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.
>
> With that in mind for an intiial solution before you get to stripping out
> the cmake stuff so that it can do an out of tree bootstrap.
> I have created a script that fits into the make bootstrapping method that
> already exists.
> Not sure if this is up for removal because it is not dependent on auto
> tools?
>
>
> I will not be stripping out any of the existing CMake. If we go down this
> path what I’m going to do is refactor the CMake to produce to logically
> separated projects so that the builtins can be built with or without the
> runtime libraries. It will all still be CMake-based.
>
> -Chris
>
>
> Chris could you kindly add yourself as a reviewer to this
> http://reviews.llvm.org/D14290
>
>
> On Tue, Nov 3, 2015 at 6:15 PM, C Bergström <cbergstrom at
pathscale.com>
> wrote:
>
>> On Wed, Nov 4, 2015 at 12:12 AM, Steve King via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > 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.
>>
>> Before anyone starts refactoring binutils - if you're really
zealous
>> or have some strong logical reason against it - there is the BSD elf
>> tools project
>>
>> http://sourceforge.net/p/elftoolchain/wiki/Home/
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/777ae780/attachment.html>

>
> 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.
+1
This was my line of thinking

On Tue, Nov 3, 2015 at 6:36 PM, Martell Malone <martellmalone at
gmail.com>
wrote:
> I will not be stripping out any of the existing CMake. If we go down this
>> path what I’m going to do is refactor the CMake to produce to logically
>> separated projects so that the builtins can be built with or without
the
>> runtime libraries. It will all still be CMake-based.
>
> Sorry. s/stripping/seperating/g
> I was still thinking about the stripping of the IOS build from the OSX
> default build :)
>
> On Tue, Nov 3, 2015 at 6:30 PM, Chris Bieneman <beanz at apple.com>
wrote:
>
>>
>> On Nov 3, 2015, at 9:24 AM, Martell Malone <martellmalone at
gmail.com>
>> wrote:
>>
>> 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.
>>
>> With that in mind for an intiial solution before you get to stripping
out
>> the cmake stuff so that it can do an out of tree bootstrap.
>> I have created a script that fits into the make bootstrapping method
that
>> already exists.
>> Not sure if this is up for removal because it is not dependent on auto
>> tools?
>>
>>
>> I will not be stripping out any of the existing CMake. If we go down
this
>> path what I’m going to do is refactor the CMake to produce to logically
>> separated projects so that the builtins can be built with or without
the
>> runtime libraries. It will all still be CMake-based.
>>
>> -Chris
>>
>>
>> Chris could you kindly add yourself as a reviewer to this
>> http://reviews.llvm.org/D14290
>>
>>
>> On Tue, Nov 3, 2015 at 6:15 PM, C Bergström <cbergstrom at
pathscale.com>
>> wrote:
>>
>>> On Wed, Nov 4, 2015 at 12:12 AM, Steve King via llvm-dev
>>> <llvm-dev at lists.llvm.org> wrote:
>>> > 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.
>>>
>>> Before anyone starts refactoring binutils - if you're really
zealous
>>> or have some strong logical reason against it - there is the BSD
elf
>>> tools project
>>>
>>> http://sourceforge.net/p/elftoolchain/wiki/Home/
>>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/5fb6f87a/attachment.html>

Thank you for bringing this up, Chris! I strongly agree with (3), i.e.
separating builtins and the rest of compiler-rt libraries (mostly
sanitizers) - they are just too different conceptually to use the same
configuration and build process.

I would love to have builtins-specific CMake functionality factored out -
stuff like choosing between C and target-specific ASM implementations of
the same functions, or generating the list of required
functions for various Apple platforms. For that matter, I'm not sure there
are that many "common" pieces of CMake configuration functionality we
should care about sharing - builtins don't require checks
for system libraries like libpthread/libdl, don't require on presence of
certain headers, or compile-time flags (-W family, -fomit-frame-pointer
etc.). What needs to be shared is the scripts used to figure out
the set of supported architectures and OSes, and I have a question here -
do you consider switching (at least builtins library) to single-arch build,
so that the user would need to setup several build trees for
each architecture they are targeting (or these trees would all be separate
ExternalProjects, if configured from, say, Clang's CMake)?

Speaking of implementation, I think it's a good idea to make lib/builtins a
valid top-level source directory for CMake invocation. Using
ExternalProject to add it from compiler-rt root is optional.

libc++/libc++abi hopefully should not be an issue, because none of
sanitizers depend on them. Sanitizers do heavily depend on libc (sometimes
even specific versions of glibc, though we do out best to hide it).

On Tue, Nov 3, 2015 at 9:42 AM, Martell Malone via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.
>
> +1
> This was my line of thinking
>
> On Tue, Nov 3, 2015 at 6:36 PM, Martell Malone <martellmalone at
gmail.com>
> wrote:
>
>> I will not be stripping out any of the existing CMake. If we go down
this
>>> path what I’m going to do is refactor the CMake to produce to
logically
>>> separated projects so that the builtins can be built with or
without the
>>> runtime libraries. It will all still be CMake-based.
>>
>> Sorry. s/stripping/seperating/g
>> I was still thinking about the stripping of the IOS build from the OSX
>> default build :)
>>
>> On Tue, Nov 3, 2015 at 6:30 PM, Chris Bieneman <beanz at
apple.com> wrote:
>>
>>>
>>> On Nov 3, 2015, at 9:24 AM, Martell Malone <martellmalone at
gmail.com>
>>> wrote:
>>>
>>> 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.
>>>
>>> With that in mind for an intiial solution before you get to
stripping
>>> out the cmake stuff so that it can do an out of tree bootstrap.
>>> I have created a script that fits into the make bootstrapping
method
>>> that already exists.
>>> Not sure if this is up for removal because it is not dependent on
auto
>>> tools?
>>>
>>>
>>> I will not be stripping out any of the existing CMake. If we go
down
>>> this path what I’m going to do is refactor the CMake to produce to
>>> logically separated projects so that the builtins can be built with
or
>>> without the runtime libraries. It will all still be CMake-based.
>>>
>>> -Chris
>>>
>>>
>>> Chris could you kindly add yourself as a reviewer to this
>>> http://reviews.llvm.org/D14290
>>>
>>>
>>> On Tue, Nov 3, 2015 at 6:15 PM, C Bergström <cbergstrom at
pathscale.com>
>>> wrote:
>>>
>>>> On Wed, Nov 4, 2015 at 12:12 AM, Steve King via llvm-dev
>>>> <llvm-dev at lists.llvm.org> wrote:
>>>> > 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.
>>>>
>>>> Before anyone starts refactoring binutils - if you're
really zealous
>>>> or have some strong logical reason against it - there is the
BSD elf
>>>> tools project
>>>>
>>>> http://sourceforge.net/p/elftoolchain/wiki/Home/
>>>>
>>>
>>>
>>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/359efa72/attachment-0001.html>