<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 03/08/2017 04:55 PM, Chris Bieneman
via llvm-dev wrote:<br>
</div>
<blockquote
cite="mid:110A9441-D0C4-4B23-843B-404E8BDBC08C@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
David,
<div class=""><br class="">
</div>
<div class="">This is an area that has had a lot of development
over the last two years.</div>
<div class=""><br class="">
</div>
<div class="">There are two supported ways in the LLVM build
system to build compiler-rt with the just-built compiler.
<div class=""><br class="">
</div>
<div class="">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.</div>
</div>
</blockquote>
<br>
Why is this not the default?<br>
<br>
Thanks again,<br>
Hal<br>
<br>
<blockquote
cite="mid:110A9441-D0C4-4B23-843B-404E8BDBC08C@apple.com"
type="cite">
<div class="">
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">-Chris</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">On Mar 8, 2017, at 2:35 PM, David Blaikie
via llvm-dev <<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class=""><br class="">
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Wed, Mar 8, 2017 at 2:03
PM Sterling Augustine <<a
moz-do-not-send="true"
href="mailto:saugustine@google.com" class="">saugustine@google.com</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="gmail_msg">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.</div>
</blockquote>
<div class=""><br class="">
I kind of roughly follow that, but not too well.<br
class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg">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.<br class="">
</div>
</div>
</blockquote>
<div class=""><br class="">
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).<br
class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg">
<div class="gmail_msg">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.)<br
class="">
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Rightio</div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="gmail_msg">
<div class="gmail_msg">
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">gnu systems have a make
variable, "CC_FOR_TARGET" that addresses
this problem. I imagine llvm should adopt a
similar mechanism inside cmake.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
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)<br class="">
<br class="">
- Dave<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_extra gmail_msg"><br
class="gmail_msg">
<div class="gmail_quote gmail_msg">On Wed, Mar
8, 2017 at 1:54 PM, David Blaikie <span
dir="ltr" class="gmail_msg"><<a
moz-do-not-send="true"
href="mailto:dblaikie@gmail.com"
class="gmail_msg" target="_blank">dblaikie@gmail.com</a>></span>
wrote:<br class="gmail_msg">
<blockquote class="gmail_quote gmail_msg"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<div dir="ltr" class="gmail_msg">I stumbled
across what seems to be a bug (to me) in
the compiler-rt build:<br
class="gmail_msg">
<br class="gmail_msg">
The compiler-rt libraries themselves are
built with the host compiler while the
tests are built and then linked with the
just-built clang.<br class="gmail_msg">
<br class="gmail_msg">
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?*<br class="gmail_msg">
<br class="gmail_msg">
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.<br class="gmail_msg">
<br class="gmail_msg">
Evgeniy - not sure if you're interested in
this or have much context? Know if this is
right/wrong/neutral, etc?<br
class="gmail_msg">
<br class="gmail_msg">
* 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)</div>
</blockquote>
</div>
<br class="gmail_msg">
</div>
</blockquote>
</div>
</div>
_______________________________________________<br
class="">
LLVM Developers mailing list<br class="">
<a moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>