[llvm-dev] Use of host/target compiler when building compiler-rt
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Wed Mar 8 15:08:46 PST 2017
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>
More information about the llvm-dev
mailing list