[llvm-dev] LLVM Weekly - #112, Feb 22nd 2016

[Alex Bradbury via llvm-dev]

LLVM Weekly - #112, Feb 22nd 2016
=================================

If you prefer, you can read a HTML version of this email at
<http://llvmweekly.org/issue/112>.

Welcome to the one hundred and twelfth 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

Filip Pizlo has written a [fantastic
article](https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/)
introducing the new B3 JIT compiler for WebKit's JavaScriptCore. This intends
to replace LLVM as the optimising backend to their fourth-tier JIT. The
article describes in detail their reasons for moving away from LLVM (mainly
compile-time) and the design trade-offs made, such as in reducing memory
allocations and minimising pointer-chasing in the IR. This reminds me of the
trade-offs Mike Pall made in the [LuaJIT 2.0
IR](http://wiki.luajit.org/SSA-IR-2.0). Philip Reames also shared [some
initial thoughts on
B3](http://www.philipreames.com/Blog/2016/02/15/quick-thoughts-on-webkits-b3/).
I know some people have expressed disappointment about WebKit moving away from
LLVM, but if you'll allow me to insert just a little bit of editorial I'd
argue B3 is a very positive development for LLVM and the wider compiler
community. B3 explores a different set of design trade-offs to those chosen
for LLVM, and these sort of changes are probably easiest to explore in a fresh
codebase.Thanks to this write-up (and hopefully future B3/AIR
documentation), we can learn from the B3 developers' experiences and consider
if some of their choices will make sense for LLVM. It's also good to remember
that LLVM isn't the only feasible route for code generation and optimisation,
and we shouldn't treat LLVM's design choices as the one-true way to do things.
Impressively, B3 was developed to its current state in only [6 months of
developer-time](https://news.ycombinator.com/item?id=11104604).

Version 0.17.0 of LDC, the LLVM-based compiler for the D programming language
has [been
released](http://forum.dlang.org/thread/cqgwucbznngoiesvbmlk@forum.dlang.org).
You can view a [detailed changelog
here](https://github.com/ldc-developers/ldc/releases/tag/v0.17.0).

GCC6 will feature a whole bunch of new warnings, and [this blog
post](https://gnu.wildebeest.org/blog/mjw/2016/02/15/looking-forward-to-gcc6-many-new-warnings/)
details many of them.

The schedule for [EuroLLVM 2016](http://www.llvm.org/devmtg/2016-03/) has now
been posted. This will be held March 17th-18th in Barcelona.


## On the mailing lists

* Bob Wilson proposes that format-security warnings in Clang [default to
error](http://lists.llvm.org/pipermail/cfe-dev/2016-February/047367.html).
Nico Weber posted a handy [summary of the
thread](http://lists.llvm.org/pipermail/cfe-dev/2016-February/047438.html).

* Sanjoy Das has posted an [RFC on adding guard intrinsics to
LLVM](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095523.html).
These would be used in a similar way to the Check opcode in WebKit's new B3
compiler.

* Alina Sbirlea proposes adding [bitcode tests to the LLVM
test-suite](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095557.html).
Hal Finkel suggests going further and just [pulling Halide in to the LLVM
test-suite](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095562.html)
as a front-end example that should provide greater test coverage.

* Andrew Trick shared some [thoughts on LLVM in light of the WebKit B3
announcement](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095463.html).
"Even when LLVM's compile time problems are largely solved, and I believe they
can be, there will always be systemic compile time and memory overhead from
design decisions that achieve generality, flexibility, and layering. These are
software engineering tradeoffs."


## LLVM commits

* The PPCLoopDataPrefetch pass has been moved to
Transforms/Scalar/LoopDataPrefetch in preparation for it becoming a
target-agnostic pass. [r261265](http://reviews.llvm.org/rL261265).

* The cmpxchg LLVM instruction now allows pointer type operands.
[r261281](http://reviews.llvm.org/rL261281).

* The X86 backend gained support for a new stack symbol ordering optimisation.
This is primarily intended to reduce code size, and produces small but
measurable improvements across some SPEC CPU 2000 benchmarks.
[r260917](http://reviews.llvm.org/rL260917).

* The LLVM C API has been extended to allow it to be used to manipulate the
datalayout. [r260936](http://reviews.llvm.org/rL260936).

* Some major work on the LazyCallGraph has been checked in.
[r261040](http://reviews.llvm.org/rL261040).

* The AMDGPU backend gained a basic disassembler.
[r261185](http://reviews.llvm.org/rL261185).

* The PostOrderFuctionAttrs pass has been ported to the new pass manager. As
described in the commit message, this actually represents a major milestone.
[r261203](http://reviews.llvm.org/rL261203).

* The Hexagon backend gained support for thread-local storage.
[r261218](http://reviews.llvm.org/rL261218).


## Clang commits

* A nullPointerConstant AST matcher was added.
[r261008](http://reviews.llvm.org/rL261008).

* Clang gained a `-Wcomma` warning, which will warn for most uses of the
builtin comma operator. [r261278](http://reviews.llvm.org/rL261278)


## Other project commits

* LLD has sprouted a release notes document.
[r260960](http://reviews.llvm.org/rL260960).

* The LLVM test-suite's CMake build system saw a number of fixes for SPEC.
[r261470](http://reviews.llvm.org/rL261470).