LLVM Weekly - #48, Dec 1st 2014 ============================== If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/48>. Welcome to the forty-eighth 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](http://asbradbury.org). 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 <asb at asbradbury.org>, or @llvmweekly or @asbradbury on Twitter. ## News and articles from around the web John Regehr has posted an [update on the Souper superoptimizer](http://blog.regehr.org/archives/1192) which he and his collaborators have been working on. They have implemented a reducer for Souper optimizations that tries to reduce the optimization to something more minimal. There current results given ~4000 distinct optimisations of which ~1500 LLVM doesn't know how to do. Of course many of these may in fact be covered by a single rule or pass. One of the next steps for Souper is to extend Souper to support the synthesis of instruction sequences. See also the [discussion on the llvm mailing list](http://article.gmane.org/gmane.comp.compilers.llvm.devel/79104). The LLVM Blog features a summary of [recent advances in loop vectorization for LLVM](http://blog.llvm.org/2014/11/loop-vectorization-diagnostics-and.html). This includes diagnostics remarks to get feedback on why loops which aren't vectorized are skipped, the loop pragma directive in Clang, and performance warnings when the directive can't be followed. The LLVM Haskell Compiler (LHC) has been [newly reborn](http://lhc-compiler.blogspot.co.uk/2014/11/the-new-lhc.html) along with [its blog](http://lhc-compiler.blogspot.co.uk/2014/11/very-minimal-hello-world.html). The next steps in development are to provide better support for Haskell2010, give reusable libraries for name resolution and type checking, and to produce human-readable compiler output. The next LLVM Social in Paris [will take place on December 9th](http://article.gmane.org/gmane.comp.debugging.lldb.devel/5830). Intel have published a blog post [detailing new X86-specific optimisations in GCC 5.0](https://software.intel.com/en-us/blogs/2014/11/24/what-is-new-for-x86-in-upcoming-gcc-50). You may also be interested in the [discussion of this post on Hacker News](https://news.ycombinator.com/item?id=8675274). ## On the mailing lists * Hal Finkel has posted an RFC suggesting the [removal of the BBVectorize pass](http://article.gmane.org/gmane.comp.compilers.llvm.devel/79192) on the basis that it hasn't progressed to production quality while the SLP vectorizer exists and has been enabled for some time and it has various bugs and code fixmes. If you feel differently, now is the time to speak up. * Yichao Yu is [curious about the current state of MCJIT for ARM](http://article.gmane.org/gmane.comp.compilers.llvm.devel/79113). Several people responded to say they've been using it with few problems on ARM, though Renato Golin [would like to see a few more success stories](http://article.gmane.org/gmane.comp.compilers.llvm.devel/79147) before marking it as 'supported' on the appropriate status page. * Tom Stellard is planning to [start the 3.5.1 release cycle](http://article.gmane.org/gmane.comp.compilers.llvm.devel/79059) shortly. Let him know if you'd like to help with testing. * When developing a non-upstreamed LLVM backend, [should you do it as a loadable module or just apply to a cloned LLVM repo](http://article.gmane.org/gmane.comp.compilers.llvm.devel/79145)? Rafael Auler has [tried the approach of building his backend as a loadable module](http://article.gmane.org/gmane.comp.compilers.llvm.devel/79191) and feels it would have been better to fork LLVM and rebase when necessary. This is the approach your esteemed editor has taken (though admittedly it's been far too long since he rebased...). ## LLVM commits * Support for `-debug-ir` (emitting the LLVM IR in debug data) was removed. There's no real justification or explanation in the commit message, but it's likely it was unfinished/unused/non-functional. [r222945](http://reviews.llvm.org/rL222945). * InstCombine will now canonicalize toward the value type being stored rather than the pointer type. The rationale (explained in more detail in the commit message) is that memory does not have a type, but operations and the values they produce do. [r222748](http://reviews.llvm.org/rL222748). * The documentation for `!invariant.load` metadata has been clarified. [r222700](http://reviews.llvm.org/rL222700). * In tablegen, neverHasSideEffects=1 is now hasSideEffects=0. [r222801](http://reviews.llvm.org/rL222801). ## Clang commits * Four new ASTMatchers have been added: typedefDecl, isInMainFile, isInSystemFile, and isInFileMatchinName. [r222646](http://reviews.llvm.org/rL222646). * The documentation on MSVC compatibility has been updated to represent the current state of affairs. Clang has also gained support for rethrowing MS C++ exceptions. [r222731](http://reviews.llvm.org/rL222731), [r222733](http://reviews.llvm.org/rL222733). ## Other project commits * Initial tests have been added for lldb-mi (the LLDB machine interface). [r222750](http://reviews.llvm.org/rL222750). * libcxxabi can now be built and tested without threads using CMake. [r222702](http://reviews.llvm.org/rL222702). * The compact-unwind-dumper tool now has complete support for x86-64 and i386 binaries. [r222951](http://reviews.llvm.org/rL222951).