[LLVMdev] Targeting ARM Cortex-a9 from x86_64 with clang

[Alp Toker]

On 27/11/2013 10:00, David Chisnall wrote:
> On 26 Nov 2013, at 19:10, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
>
>> On Tue, Nov 26, 2013 at 12:40:17PM -0500, Sean Silva wrote:
>>> Well, just remember that the GNU binutils that those tools are derived from
>>> support far more architectures (3x, 5x?) than LLVM does (just supporting
>>> linux requires like 30 architectures). When we get to that point, it will
>>> probably not make sense for a distro to ship a binary targeting all the
>>> architectures that we support, for the same reason it doesn't make sense
>>> for them to install binaries for every target supported by the GNU
>>> toolchain.
>> I know that FreeBSD limits the set of targets by default mostly for
>> compile reasons, the size difference is not that big. The trade off is
>> *much* better with LLVM.
> We only do it, I believe, for the bootstrap build.  When you build FreeBSD, you first build the toolchain that you'll build the system with (from the source tree that you're going to build, for the host arch), then you build the tree with that toolchain (for whatever your target arch is).  Given how much of the total build time LLVM / Clang accounts for, building it twice caused a lot of irritating.  We quite aggressively stripped down the bootstrap build, so that it only supports the specified target (unless requested otherwise), doesn't include the Clang rewriter, the static analyser, and a few other things.  Removing the JIT would probably also make sense.

Since you're on the topic and this thread has already gone off on a 
tangent..

While investigating vendor patches on various third party LLVM branches, 
I noticed FreeBSD also strips out the entire LLVM and clang test suites 
from the repository.

As a result, some of the platform-specific changes and cherry-picks from 
upstream don't appear to have obvious tests despite being a little 
invasive. Are the related tests hiding away in a surrogate repository 
somewhere or is it more of a "compiles, then ship it" policy?

(Not intended as a criticism, rather that I've been trying to understand 
how external projects are consuming clang so we might accommodate them 
better upstream, eg. by providing a streamlined boostrap configuration.)

Alp.


>
> David
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 
http://www.nuanti.com
the browser experts