llvm dev - Mar 2017 - Use of host/target compiler when building compiler-rt

On 03/08/2017 04:55 PM, Chris Bieneman via llvm-dev
wrote:
> David,
>
> This is an area that has had a lot of development over the last two years.
>
> There are two supported ways in the LLVM build system to build 
> compiler-rt with the just-built compiler.
>
> 1) The legacy way is for if compiler-rt is under LLVM/projects. You 
> can specify -DLLVM_BUILD_EXTERNAL_COMPILER_RT=On, which will configure 
> compiler-rt using the just-built clang after clang is built.
Why is this not the default?

Thanks again,
Hal
>
> 2) The new way, is to place compiler-rt under LLVM/runtimes. In this 
> path the build system will automatically build with the just-built 
> compiler. This path also splits compiler-rt into two separate build 
> steps, one that configures and builds the builtins with the just-built 
> compiler, and a second that configures and builds the sanitizer libraries.
>
> The second path also works for many (but not all) of our other runtime 
> library projects. I know it works for libcxx, libcxxabi, and 
> libunwind. Petr Hosek (CC'd) has also been working on support for 
> multi-arch builtin and runtime library builds so that you can generate 
> full cross-compilers from a single cmake invocation.
>
> -Chris
>
>
>> On Mar 8, 2017, at 2:35 PM, David Blaikie via llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>
>>
>>
>> On Wed, Mar 8, 2017 at 2:03 PM Sterling Augustine 
>> <saugustine at google.com <mailto:saugustine at
google.com>> wrote:
>>
>>     Yes, this is a aspect of the larger problem that clang bootstrap
>>     doesn't work for a cross-compiler. The build (mostly?) assumes
>>     that host==target during the build of clang itself, and then if
>>     you want another architecture also, you run a second build of the
>>     target libraries, and manually merge the trees.
>>
>>
>> I kind of roughly follow that, but not too well.
>>
>>     If you think about compiler-rt as being compiled for the target
>>     rather than the host, the problem you describe here is exactly
>>     the same one, and we have been getting lucky.
>>
>>
>> Sure - if a PPC clang is being built from an x86 host, how would 
>> compiler-rt be built (OK, it could be built with the just-built 
>> clang, which it isn't at the moment) and tested (can't really
be
>> tested because the host can't run PPC binaries).
>>
>>     At the moment, the blaze builds of clang do exactly the procedure
>>     described above, so this hasn't been a terrible problem for
>>     Google, but I do think it is something that should be fixed
(I'm
>>     working on another aspect of compiler-rt bringup at the moment,
>>     so won't solve this in the immediate future.)
>>
>>
>> Rightio
>>
>>
>>     gnu systems have a make variable, "CC_FOR_TARGET" that
addresses
>>     this problem. I imagine llvm should adopt a similar mechanism
>>     inside cmake.
>>
>>
>> Not sure I follow on the need/use of CC_FOR_TARGET compared to using 
>> the just-built clang as the CC_FOR_TARGET (which it seems we have 
>> some plumbing for already - the just-built clang is used for building 
>> the compiler-rt tests, but not for building the library. I /think/ it 
>> should be used for both)
>>
>> - Dave
>>
>>
>>     On Wed, Mar 8, 2017 at 1:54 PM, David Blaikie <dblaikie at
gmail.com
>>     <mailto:dblaikie at gmail.com>> wrote:
>>
>>         I stumbled across what seems to be a bug (to me) in the
>>         compiler-rt build:
>>
>>         The compiler-rt libraries themselves are built with the host
>>         compiler while the tests are built and then linked with the
>>         just-built clang.
>>
>>         It was my understanding that the goal/intent/need was to have
>>         the compiler-rt library build with the just-built clang? Did
>>         I misunderstand that?*
>>
>>         Sterling: Chandler seemed to think you might be interested in
>>         this issue & possibly addressing it given you're
working on
>>         compiler-rt bring-up? It'd probably be useful to have
>>         compiler-rt built with the just-built clang for performance
>>         reasons.
>>
>>         Evgeniy - not sure if you're interested in this or have
much
>>         context? Know if this is right/wrong/neutral, etc?
>>
>>         * reasons include performance, ABI compatibility, etc (I
>>         thought this was necessary for correctness in some way) -
>>         also, otherwise it seems excessive to hold up the whole build
>>         on waiting for just-built clang to finish, then use that to
>>         compile some tests. (well, I realize some of the tests are
>>         end-to-end, so they do need the just-built compiler)
>>
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170308/8f91be65/attachment-0001.html>

> On Mar 8, 2017, at 3:08 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> 
> On 03/08/2017 04:55 PM, Chris Bieneman via llvm-dev wrote:
>> David,
>> 
>> This is an area that has had a lot of development over the last two
years.
>> 
>> There are two supported ways in the LLVM build system to build
compiler-rt with the just-built compiler.
>> 
>> 1) The legacy way is for if compiler-rt is under LLVM/projects. You can
specify -DLLVM_BUILD_EXTERNAL_COMPILER_RT=On, which will configure compiler-rt
using the just-built clang after clang is built.
> 
> Why is this not the default?
Two reasons. (1) It is buggy, and nobody fixed the issues because (2) the
long-term plan is to not support building compiler-rt (or any other runtime
library) under llvm/projects. The goal is to migrate entirely to llvm/runtimes
where the support is more complete.

-Chris
> 
> Thanks again,
> Hal
> 
>> 
>> 2) The new way, is to place compiler-rt under LLVM/runtimes. In this
path the build system will automatically build with the just-built compiler.
This path also splits compiler-rt into two separate build steps, one that
configures and builds the builtins with the just-built compiler, and a second
that configures and builds the sanitizer libraries.
>> 
>> The second path also works for many (but not all) of our other runtime
library projects. I know it works for libcxx, libcxxabi, and libunwind. Petr
Hosek (CC'd) has also been working on support for multi-arch builtin and
runtime library builds so that you can generate full cross-compilers from a
single cmake invocation.
>> 
>> -Chris
>> 
>> 
>>> On Mar 8, 2017, at 2:35 PM, David Blaikie via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>> 
>>> 
>>> 
>>> On Wed, Mar 8, 2017 at 2:03 PM Sterling Augustine <saugustine at
google.com <mailto:saugustine at google.com>> wrote:
>>> Yes, this is a aspect of the larger problem that clang bootstrap
doesn't work for a cross-compiler. The build (mostly?) assumes that
host==target during the build of clang itself, and then if you want another
architecture also, you run a second build of the target libraries, and manually
merge the trees.
>>> 
>>> I kind of roughly follow that, but not too well.
>>>  
>>> If you think about compiler-rt as being compiled for the target
rather than the host, the problem you describe here is exactly the same one, and
we have been getting lucky.
>>> 
>>> Sure - if a PPC clang is being built from an x86 host, how would
compiler-rt be built (OK, it could be built with the just-built clang, which it
isn't at the moment) and tested (can't really be tested because the host
can't run PPC binaries).
>>>  
>>> At the moment, the blaze builds of clang do exactly the procedure
described above, so this hasn't been a terrible problem for Google, but I do
think it is something that should be fixed (I'm working on another aspect of
compiler-rt bringup at the moment, so won't solve this in the immediate
future.)
>>> 
>>> Rightio
>>>  
>>> 
>>> gnu systems have a make variable, "CC_FOR_TARGET" that
addresses this problem. I imagine llvm should adopt a similar mechanism inside
cmake.
>>> 
>>> Not sure I follow on the need/use of CC_FOR_TARGET compared to
using the just-built clang as the CC_FOR_TARGET (which it seems we have some
plumbing for already - the just-built clang is used for building the compiler-rt
tests, but not for building the library. I /think/ it should be used for both)
>>> 
>>> - Dave
>>>  
>>> 
>>> On Wed, Mar 8, 2017 at 1:54 PM, David Blaikie <dblaikie at
gmail.com <mailto:dblaikie at gmail.com>> wrote:
>>> I stumbled across what seems to be a bug (to me) in the compiler-rt
build:
>>> 
>>> The compiler-rt libraries themselves are built with the host
compiler while the tests are built and then linked with the just-built clang.
>>> 
>>> It was my understanding that the goal/intent/need was to have the
compiler-rt library build with the just-built clang? Did I misunderstand that?*
>>> 
>>> Sterling: Chandler seemed to think you might be interested in this
issue & possibly addressing it given you're working on compiler-rt
bring-up? It'd probably be useful to have compiler-rt built with the
just-built clang for performance reasons.
>>> 
>>> Evgeniy - not sure if you're interested in this or have much
context? Know if this is right/wrong/neutral, etc?
>>> 
>>> * reasons include performance, ABI compatibility, etc (I thought
this was necessary for correctness in some way) - also, otherwise it seems
excessive to hold up the whole build on waiting for just-built clang to finish,
then use that to compile some tests. (well, I realize some of the tests are
end-to-end, so they do need the just-built compiler)
>>> 
>>> _______________________________________________
>>> 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>
>> 
>> 
>> 
>> _______________________________________________
>> 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>
> 
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170308/85b1e908/attachment.html>

For additional context, please see this thread from August:
http://lists.llvm.org/pipermail/llvm-dev/2016-August/104174.html
<http://lists.llvm.org/pipermail/llvm-dev/2016-August/104174.html>

-Chris
> On Mar 8, 2017, at 3:14 PM, Chris Bieneman via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
>> 
>> On Mar 8, 2017, at 3:08 PM, Hal Finkel <hfinkel at anl.gov
<mailto:hfinkel at anl.gov>> wrote:
>> 
>> 
>> On 03/08/2017 04:55 PM, Chris Bieneman via llvm-dev wrote:
>>> David,
>>> 
>>> This is an area that has had a lot of development over the last two
years.
>>> 
>>> There are two supported ways in the LLVM build system to build
compiler-rt with the just-built compiler.
>>> 
>>> 1) The legacy way is for if compiler-rt is under LLVM/projects. You
can specify -DLLVM_BUILD_EXTERNAL_COMPILER_RT=On, which will configure
compiler-rt using the just-built clang after clang is built.
>> 
>> Why is this not the default?
> 
> Two reasons. (1) It is buggy, and nobody fixed the issues because (2) the
long-term plan is to not support building compiler-rt (or any other runtime
library) under llvm/projects. The goal is to migrate entirely to llvm/runtimes
where the support is more complete.
> 
> -Chris
> 
>> 
>> Thanks again,
>> Hal
>> 
>>> 
>>> 2) The new way, is to place compiler-rt under LLVM/runtimes. In
this path the build system will automatically build with the just-built
compiler. This path also splits compiler-rt into two separate build steps, one
that configures and builds the builtins with the just-built compiler, and a
second that configures and builds the sanitizer libraries.
>>> 
>>> The second path also works for many (but not all) of our other
runtime library projects. I know it works for libcxx, libcxxabi, and libunwind.
Petr Hosek (CC'd) has also been working on support for multi-arch builtin
and runtime library builds so that you can generate full cross-compilers from a
single cmake invocation.
>>> 
>>> -Chris
>>> 
>>> 
>>>> On Mar 8, 2017, at 2:35 PM, David Blaikie via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>>> 
>>>> 
>>>> 
>>>> On Wed, Mar 8, 2017 at 2:03 PM Sterling Augustine
<saugustine at google.com <mailto:saugustine at google.com>> wrote:
>>>> Yes, this is a aspect of the larger problem that clang
bootstrap doesn't work for a cross-compiler. The build (mostly?) assumes
that host==target during the build of clang itself, and then if you want another
architecture also, you run a second build of the target libraries, and manually
merge the trees.
>>>> 
>>>> I kind of roughly follow that, but not too well.
>>>>  
>>>> If you think about compiler-rt as being compiled for the target
rather than the host, the problem you describe here is exactly the same one, and
we have been getting lucky.
>>>> 
>>>> Sure - if a PPC clang is being built from an x86 host, how
would compiler-rt be built (OK, it could be built with the just-built clang,
which it isn't at the moment) and tested (can't really be tested because
the host can't run PPC binaries).
>>>>  
>>>> At the moment, the blaze builds of clang do exactly the
procedure described above, so this hasn't been a terrible problem for
Google, but I do think it is something that should be fixed (I'm working on
another aspect of compiler-rt bringup at the moment, so won't solve this in
the immediate future.)
>>>> 
>>>> Rightio
>>>>  
>>>> 
>>>> gnu systems have a make variable, "CC_FOR_TARGET"
that addresses this problem. I imagine llvm should adopt a similar mechanism
inside cmake.
>>>> 
>>>> Not sure I follow on the need/use of CC_FOR_TARGET compared to
using the just-built clang as the CC_FOR_TARGET (which it seems we have some
plumbing for already - the just-built clang is used for building the compiler-rt
tests, but not for building the library. I /think/ it should be used for both)
>>>> 
>>>> - Dave
>>>>  
>>>> 
>>>> On Wed, Mar 8, 2017 at 1:54 PM, David Blaikie <dblaikie at
gmail.com <mailto:dblaikie at gmail.com>> wrote:
>>>> I stumbled across what seems to be a bug (to me) in the
compiler-rt build:
>>>> 
>>>> The compiler-rt libraries themselves are built with the host
compiler while the tests are built and then linked with the just-built clang.
>>>> 
>>>> It was my understanding that the goal/intent/need was to have
the compiler-rt library build with the just-built clang? Did I misunderstand
that?*
>>>> 
>>>> Sterling: Chandler seemed to think you might be interested in
this issue & possibly addressing it given you're working on compiler-rt
bring-up? It'd probably be useful to have compiler-rt built with the
just-built clang for performance reasons.
>>>> 
>>>> Evgeniy - not sure if you're interested in this or have
much context? Know if this is right/wrong/neutral, etc?
>>>> 
>>>> * reasons include performance, ABI compatibility, etc (I
thought this was necessary for correctness in some way) - also, otherwise it
seems excessive to hold up the whole build on waiting for just-built clang to
finish, then use that to compile some tests. (well, I realize some of the tests
are end-to-end, so they do need the just-built compiler)
>>>> 
>>>> _______________________________________________
>>>> 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>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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>
>> 
>> -- 
>> Hal Finkel
>> Lead, Compiler Technology and Programming Languages
>> Leadership Computing Facility
>> Argonne National Laboratory
> 
> _______________________________________________
> 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/20170308/27dc1ff8/attachment.html>

> On Mar 8, 2017, at 3:14 PM, Chris Bieneman via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
>> On Mar 8, 2017, at 3:08 PM, Hal Finkel <hfinkel at anl.gov
<mailto:hfinkel at anl.gov>> wrote:
>> 
>> 
>> On 03/08/2017 04:55 PM, Chris Bieneman via llvm-dev wrote:
>>> David,
>>> 
>>> This is an area that has had a lot of development over the last two
years.
>>> 
>>> There are two supported ways in the LLVM build system to build
compiler-rt with the just-built compiler.
>>> 
>>> 1) The legacy way is for if compiler-rt is under LLVM/projects. You
can specify -DLLVM_BUILD_EXTERNAL_COMPILER_RT=On, which will configure
compiler-rt using the just-built clang after clang is built.
>> 
>> Why is this not the default?
> 
> Two reasons. (1) It is buggy, and nobody fixed the issues because (2) the
long-term plan is to not support building compiler-rt (or any other runtime
library) under llvm/projects. The goal is to migrate entirely to llvm/runtimes
where the support is more complete.
>From a compiler developers point of view I wanted to stress that we at least
should keep the option not to do it, as in my experience development workflow
heavily slows down if you have to wait around for compiler-rt to rebuild after
every small change you make to the compiler.
Of course I agree that we should switch the default to something that uses the
just-built compiler so people unaware of these issues get the safe and correct
thing.

- Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170308/4cef946f/attachment.html>