[llvm-dev] Use of host/target compiler when building compiler-rt

Wed Mar 8 15:16:41 PST 2017

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>