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

On Wed, Mar 8, 2017 at 2:03 PM Sterling Augustine <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>
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)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170308/b01e23a8/attachment.html>

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.

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> 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
> 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/d3d35b9c/attachment.html>

I think the long term plan is to build compiler-rt with just build
clang. Nothing else makes sense, really. AFAIK that's what
LLVM_BUILD_EXTERNAL_COMPILER_RT is for.

On Wed, Mar 8, 2017 at 2:35 PM, David Blaikie <dblaikie at gmail.com>
wrote:
>
>
> On Wed, Mar 8, 2017 at 2:03 PM Sterling Augustine <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> 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)
>>
>>
>

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 Wed, Mar 8, 2017 at 2:55 PM Chris Bieneman <beanz at apple.com> 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.
>
I thought the BUILD_EXTERNAL variables were for use when projects were not
embedded within the llvm source tree (mostly in use by Takumi's flat
buildbots that checout the top-level project without embedding, say, clang
or compiler-rt within the llvm source tree)?

>
> 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.
>
Huh, OK - could someone remove the legacy format, then? If it's a trap.

That said, I tried putting compiler-rt in runtimes instead of projects and
I got a bunch of cmake errors starting with:

CMake Error at
/usr/local/google/home/blaikie/dev/llvm/build/clang/debug/split/notypes/nostandalone/lib/cmake/llvm/AddLLVM.cmake:1174
(add_dependencies):
  The dependency target "GotsanRuntimeCheck" of target
"check-runtimes" does
  not exist.
Call Stack (most recent call first):
  CMakeLists.txt:110 (add_lit_target)

Any ideas?

>
> 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> wrote:
>
>
>
> On Wed, Mar 8, 2017 at 2:03 PM Sterling Augustine <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>
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
> 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/b57f5ca7/attachment.html>