Fwd: [cfe-dev] Using clang as production compiler for chrome/mac
Rafael Ávila de Espíndola
I have been planning on posting something like this to dev-planning,
but I wanted to first fix the performance regression that switching
to clang would cause.
I have been trying hard (llvm.org/pr10096, llvm.org/pr10251,
llvm.org/pr10287, llvm.org/pr10292), but there is still a small
regression in the js interpreter performance.
Building with clang would have some advantages:
*) gcc is gone from xcode 4.2. All new features Apple implements
will be clang only.
*) build time is smaller, even with optimizations enabled.
*) with the switch to vc 2010, gcc 4.2 would become the oldest
compiler we use, blocking the adoption of any new c++ features.
*) shark shows that the non-interpreter bits are getting less
hits, so we might even get a performance boost once those
bugs are fixed.
*) clang produces smaller binaries.
See the posts in http://blog.mozilla.com/respindola for more info.
As for which versions of clang to use, I had considered two options
*) The open source clang 3.0 once it is released (it is trunk right now).
*) The one include in Xcode 4.1 or newer (4.0 miscompiles firefox)
My preference would be to use the open source one. We get benefits
on linux by controlling the compiler, in this case the benefits
would be even bigger as I am a lot more familiar with llvm/clang
than gcc these days.
Nico's idea of using trunk is interesting. I am not sure I would
propose doing the nightly builds with it, but having a bot
that builds m-c with trunk could be useful.
-------- Original Message --------
Subject: [cfe-dev] Using clang as production compiler for chrome/mac
Date: Sat, 9 Jul 2011 17:34:48 -0700
From: Nico Weber <tha...@chromium.org>
To: cfe...@cs.uiuc.edu Developers <cfe...@cs.uiuc.edu>
Hi,
we're currently using clang for its diagnostics in chromium land, but
we'd like to use it to build our shipping binary in the future too.
One thing we're wondering about is which clang version to use for
this. Currently, we're pulling a fixed revision from the llvm svn
server and I update that revision about once a week.
One of the alternatives is to use trunk for our shipping binaries as
well. Chromium has three different channels – dev, beta, stable – and
we could use trunk for the dev channel and then branch clang with the
rest of our source for the beta and stable channels and only merge
"important" clang/llvm changes to there. Shipping a product that's
built with a potentially unstable compiler sounds a bit risky, so why
haven't I discarded this alternative already?
I imagine that it might be useful for the clang project, since we have
quite a bit of monitoring in chromium land (automated perf graphs,
compile time graphs, crash reporting that $many users have opted in
to), so that we could find and report regressions in clang reasonably
quickly. Do you think this is interesting at all?
Nico
_______________________________________________
cfe-dev mailing list
cfe...@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Rafael Ávila de Espíndola
Ehsan Akhgari
I'm very much in favor of us building and testing Firefox with
clang/llvm, because of all the points you mention, and also the fact
that clang provides a new window of opportunity for us to build cool
tools (such as Joshua Cranmer's recent DXR rewrite project).
I think in addition to trying to fix clang/llvm, we should also take
care not to land incorrect code into our repository which breaks clang
builds.
Right now, for example, m-c cannot be compiled with clang because of bug
557226 (I'm landing the patch as we speak!). I know that you've been
working with releng in order to get clang builds going. Can you please
let us know about the status of that project? I think having clang
builds as soon as possible is valuable even before we can get all
clang/llvm problems fixed.
Cheers,
Ehsan
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Rafael Ávila de Espíndola
> Thanks Rafael for your post.
>
> I'm very much in favor of us building and testing Firefox with
> clang/llvm, because of all the points you mention, and also the fact
> that clang provides a new window of opportunity for us to build cool
> tools (such as Joshua Cranmer's recent DXR rewrite project).
>
> I think in addition to trying to fix clang/llvm, we should also take
> care not to land incorrect code into our repository which breaks clang
> builds.
>
> Right now, for example, m-c cannot be compiled with clang because of bug
> 557226 (I'm landing the patch as we speak!). I know that you've been
> working with releng in order to get clang builds going. Can you please
> let us know about the status of that project? I think having clang
> builds as soon as possible is valuable even before we can get all
> clang/llvm problems fixed.
The status is that the mac bots have a copy of clang that works on
opt builds. It has one failure on 64 bits debug because the
interpreter uses too much stack space. Debug builds on 32 bits
have more failure, which I assume is because they hit the stack
limit more often.
The linux bots have a build too, but they try to use the really
old 4.1 c++ that we have on the bots and fail. I have figured
out how to build with the same 4.5 headers we use for gcc.
I have been trying to fix the performance problems, that is why
I didn't try to get a new version up. Since you see value in it,
I will swap the priorities. Currently the build is broken on
the llvm side too (PR10340). As soon as that is fixed I will
create a bug with a patched spec file and try to figure out
how to upgrade the mac builds.
> Cheers,
> Ehsan
Cheers,
Rafael