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

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 22 03:26:57 PST 2016

LLVM Weekly - #112, Feb 22nd 2016

If you prefer, you can read a HTML version of this email at

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

Version 0.17.0 of LDC, the LLVM-based compiler for the D programming language
has [been
You can view a [detailed changelog

GCC6 will feature a whole bunch of new warnings, and [this blog
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
Nico Weber posted a handy [summary of the

* Sanjoy Das has posted an [RFC on adding guard intrinsics to
These would be used in a similar way to the Check opcode in WebKit's new B3

* Alina Sbirlea proposes adding [bitcode tests to the LLVM
Hal Finkel suggests going further and just [pulling Halide in to the LLVM
as a front-end example that should provide greater test coverage.

* Andrew Trick shared some [thoughts on LLVM in light of the WebKit B3
"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.

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

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

* The AMDGPU backend gained a basic disassembler.

* The PostOrderFuctionAttrs pass has been ported to the new pass manager. As
described in the commit message, this actually represents a major milestone.

* The Hexagon backend gained support for thread-local storage.

## Clang commits

* A nullPointerConstant AST matcher was added.

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

* The LLVM test-suite's CMake build system saw a number of fixes for SPEC.

More information about the llvm-dev mailing list