Monday, December 1, 2014

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

The LLVM Blog features a summary of recent advances in loop vectorization for
LLVM.
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 along
with its
blog.
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.

On the mailing lists

Hal Finkel has posted an RFC suggesting the removal of the BBVectorize
pass 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.

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.

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.

The documentation for !invariant.load metadata has been clarified.
r222700.