LLVM Weekly - #26, Jun 30th 2014
Welcome to the twenty-sixth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by Alex Bradbury. Subscribe to future issues at http://llvmweekly.org and pass it on to anyone else you think may be interested. Please send any tips or feedback to firstname.lastname@example.org, or @llvmweekly or @asbradbury on Twitter.
The canonical home for this issue can be found here at llvmweekly.org.
News and articles from around the web
Vladmir Makarov has done his yearly comparison of GCC and LLVM, posting performance comparisons using SPECInt2000 on ARM and x86-64.
Version 0.13.0 of LDC, the LLVM-based D compiler has been released. This brings a whole host of improvements, listed in detail within the release announcement.
Some Mozilla engineers have been looking at using clang-cl (the MSVC-compatible Clang driver) to build Firefox. With the help of the fallback flag (which falls back o compiling with MSVC if Clang fails) they've managed to get a completed build. Ehsan tells us that 602 of the 7168 files, about 8% require the MSVC fallback at the moment.
Trail of Bits have posted a preview of McSema, a framework for translating x86 binaries to LLVM bitcode. The accompanying talk took place on the 28th June, so hopefully we'll hear more about this soon. The blog post tells us that McSema will be open source and made available soon.
Bruce Mitchener has written up his experience of integrating with LLDB for Dylan.
Codeplay (based in Edinburgh) are advertising for a full time compiler engineer.
On the mailing lists
Alp Toker kicked off a long thread about the use of Phabricator for code reviews. The main problem is that Phabricator reviews aren't necessarily going through llvm-commits which is potentially harming development. A very sensible step has been taken of filing a feature request with Phabricator for the ability to warn when no mailing list is subscribed to a code review.
James Molloy has shared some rough benchmark data on LLVM targeting Cortex-A57. For SPEC, LLVM is apparently less than 5% behind GCC for most benchmarks. James also lists a number of missed optimisation opportunities he's noticed so far in comparing the output.
Alexander Kornienko questions whether it's time to bump the minimum Python requirement from 2.5 to 2.7. Replies o the thread made the distinction between the minimum to run tests using lit (which is written in Python) and the minimum for tooling scripts that may need to be less portable. Despite 2.5 being ancient, the reason for wanting to support it is for long-lived releases such as RHEL.
Diego Novillo suggests turning on debug column info by default. He found almost no difference in compile time and only a 1% growth in debug info size. There seems to be support for doing this, with the only concern being that some debuggers might not interpret the data properly leading to odd behaviour. David Blaikie found a few regressions in the gdb test suite, but has yet to investigate further.
A significant overhaul of how vector lowering is done in the x86 backend has been started. While it's under development it's off by default, though it's hoped that in times there will be measurable performance improvements on benchmarks conducive to vectorization. r211888 and more.
X86 FastISel will use EFLAGS directly when lowering select instructions if the condition comes from a compare. It also now supports floating-point selects among other improvements. r211543, r211544, and more.
ScaledNumber has been split out from BlockFrequencyInfo into the Support library. r211562.
The loop vectorizer now features
The developer documentation has been updated to clarify that although you can use Phabricator to submit code for review, you should also ensure the relevant -commits mailing list is added as a subscriber on the review and be prepared to respond to comments there. r211731.
LLVM gained an abstraction for a random number generator (RNG). r211705.
A nice little diagnostic improvement has been added for when the user accidentally puts braces before the identifer, e.g.
int  foo;. r211641.