[LLVMdev] LLVM Weekly - #48, Dec 1st 2014

[Alex Bradbury]

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).