Nico Weber
2014-Nov-13 18:40 UTC
[LLVMdev] [announce] Chrome now uses clang for production builds on Linux
Hi, As of Chrome m38, which shipped to stable a bit over a month ago, we are using clang as our production compiler for Linux – meaning that the bits we ship to users on Linux are now created by clang. It's now also our default host compiler for Chrome/Android builds (the target compiler is still gcc). We used to use gcc 4.6 before. Maybe this is interesting to others, hence this (somewhat belated) announcement. We're using the same model we use on OS X: We use a pinned clang revision without any changes (these days, we sometimes cherrypick a few newer versions every now and then) that we update to ~trunk every few weeks. The switch went off without larger problems, except one: The linux binaries that clang produces by default don't run on older 32-bit debians, an issue that we didn't find until our stable release. This is due to clang making assumptions about alignment that aren't true on 32-bit in practice. We worked around this and got an updated stable out relatively quickly, but producing broken 32-bit binaries by default is a great opportunity for improvement :-) I filed http://llvm.org/PR21414 for this. With the switch to clang, binary size dropped about 8% while performance mostly stayed the same. Startup time improved a bit, some microbenchmarks got faster, others got slower (I debugged the biggest slowdown, that turned out to be a benchmark bug). If you're interested https://chromeperf.appspot.com/group_report?rev=282246 has details, ignore all rows that aren't for "linux-release" or "chromium-rel-linux". page_cycler.tough_layout_cases for example got 2.5% faster, which is nice. Thanks everyone for all your work building such a great compiler! Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141113/6721700b/attachment.html>
Sean Silva
2014-Nov-13 23:55 UTC
[LLVMdev] [announce] Chrome now uses clang for production builds on Linux
Congratulations! On Thu, Nov 13, 2014 at 10:40 AM, Nico Weber <thakis at chromium.org> wrote:> Hi, > > As of Chrome m38, which shipped to stable a bit over a month ago, we are > using clang as our production compiler for Linux – meaning that the bits we > ship to users on Linux are now created by clang. It's now also our default > host compiler for Chrome/Android builds (the target compiler is still gcc). > We used to use gcc 4.6 before. Maybe this is interesting to others, hence > this (somewhat belated) announcement. > > We're using the same model we use on OS X: We use a pinned clang revision > without any changes (these days, we sometimes cherrypick a few newer > versions every now and then) that we update to ~trunk every few weeks. > > The switch went off without larger problems, except one: The linux > binaries that clang produces by default don't run on older 32-bit debians, > an issue that we didn't find until our stable release. This is due to clang > making assumptions about alignment that aren't true on 32-bit in practice. > We worked around this and got an updated stable out relatively quickly, but > producing broken 32-bit binaries by default is a great opportunity for > improvement :-) I filed http://llvm.org/PR21414 for this. > > With the switch to clang, binary size dropped about 8% while performance > mostly stayed the same. Startup time improved a bit, some microbenchmarks > got faster, others got slower (I debugged the biggest slowdown, that turned > out to be a benchmark bug). If you're interested > https://chromeperf.appspot.com/group_report?rev=282246 has details, > ignore all rows that aren't for "linux-release" or "chromium-rel-linux". > page_cycler.tough_layout_cases for example got 2.5% faster, which is nice. > > Thanks everyone for all your work building such a great compiler! > > Nico > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141113/f58b6262/attachment.html>