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

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

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.

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.

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.)

gnu systems have a make variable, "CC_FOR_TARGET" that addresses this
problem. I imagine llvm should adopt a similar mechanism inside cmake.

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

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>