[LLVMdev] LLVM Weekly - #14, Apr 7th 2014

[Alex Bradbury]

LLVM Weekly - #14, Apr 7th 2014
===============================

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

Welcome to the fourteenth 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.

There seems to have been a flood of LLVM-related news this week, hopefully
I've managed to collect it all. If you're in London next week, you might be
interested in attending [my introductory LLVM
talk](http://www.meetup.com/X-Dev-London/events/174666532/) on Wednesday.
Abstract is [here](http://pastebin.com/StSzTzMv).

EuroLLVM is of course taking place on Monday and Tuesday of this week. Sadly I
won't be in attendance. If anyone is blogging the event, please do send me
links.

## News and articles from around the web

The LLVM-related news that has made the biggest splash this week is surely the
[announcement of Pyston, a JIT for Python targeting
LLVM](https://tech.dropbox.com/2014/04/introducing-pyston-an-upcoming-jit-based-python-implementation/).
More technical details are [available on the Github
repo](https://github.com/dropbox/pyston#technical-features). For many this
immediately conjures up memories of the [Unladen Swallow
project](http://code.google.com/p/unladen-swallow/), started by Google
engineers with the same aim of JITting Python with LLVM. That project was
eventually unsuccessful, but it's unfair to the authors of Pyston to assume it
will have the same fate. It's unclear how much developer time Dropbox are
contributing to Pyston. They clearly have a lot of work to do, though it's no
secret that [Apple are also looking to target LLVM from
JavaScript](http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066573.html)
which means they're not the only developers working in this area. Kevin
Modzelewski [shared some more
info](http://article.gmane.org/gmane.comp.compilers.llvm.devel/71870) on the
LLVM mailing list which details some of the LLVM work they've implemented so
far (including some initial escape analysis for GCed memory).

An independent, non-profit LLVM Foundation [is to be
formed](http://blog.llvm.org/2014/04/the-llvm-foundation.html). As a vendor
neutral organisation it will represent the community interest and aims to be
set up by the end of the year.The initial board of directors will be Vikram
Adve, Chandler Carruth, Doug Gregor, David Kipping, Anton Korobeynikov, Chris
Lattner, Tanya Lattner, and Alex Rosenberg.

Rust 0.10 [has been
released](https://mail.mozilla.org/pipermail/rust-dev/2014-April/009387.html).
See also the discussion on [Hacker
News](https://news.ycombinator.com/item?id=7524945) and
[Reddit](http://www.reddit.com/r/programming/comments/224gh2/rust_010_released/).
Rust is a systems programming language from Mozilla which uses LLVM as its
code generator backend.

The [Dagger](http://dagger.repzret.org/) LLVM-based decompilation framework
has [released its
source](http://dagger.repzret.org/update-a-sneak-peek-of-the-source/) as well
as publishing a series of five articles documenting its implementation
approach and documenting the next steps or 'TODOs'.

An [LLVM backend for the Accelerate Array
Language](https://github.com/AccelerateHS/accelerate-llvm) has been released.
It compiles Accelerate code to LLVM IR and can target multicore CPUs as well
as NVIDIA GPUs.

The [PDF slides](https://github.com/gannimo/MalDiv/raw/master/paper/talk_payerm_syscan14.pdf)
for a recent talk about the LLVM-based
[MalDiv](https://github.com/gannimo/MalDiv) diversifying compiler have been
published. Such a tool effectively defeats signature-based matching of
malware.

## On the mailing lists

* James Molloy from ARM has been looking at the recently open sourced ARM64
backend from Apple, and has come to the conclusion that [it's easier to use
ARM64 as a base an merge in from
AArch64](article.gmane.org/gmane.comp.compilers.llvm.devel/71737). The key
justification is that ARM64 backend is more performant but has some
correctness issues, and porting performance fixes is more difficult than
correctness. There seems to be agreement from the followup responses. Bradley
Smith reports [good progress on fixing observed correctness issues and some
interesting performance
results](http://article.gmane.org/gmane.comp.compilers.llvm.devel/71861). Of
interest to those attending EuroLLVM this week, there will be discussions on
Monday and after the main conference on Wednesday (details
[here](http://article.gmane.org/gmane.comp.compilers.llvm.devel/71947)).

* Requests for patches to be included in LLVM/Clang 3.4.1 have started to come
in. These include [a large number of AArch64
patches](http://article.gmane.org/gmane.comp.compilers.llvm.devel/71788) (plus
[another](http://article.gmane.org/gmane.comp.compilers.llvm.devel/71849)),
plus some [assorted
bugfixes](http://article.gmane.org/gmane.comp.compilers.llvm.devel/71809).

* Reid Kleckner has [proposed a new tail call
marker](http://article.gmane.org/gmane.comp.compilers.llvm.devel/71775),
'musttail' which guarantees that tail call optimization will occur.

* Shankar Easwaran starts a discussion on [adding support to lld for
demangling
symbols](http://article.gmane.org/gmane.comp.compilers.llvm.devel/71852).

* Jeroen Dobbelaere has an [interesting
problem](http://article.gmane.org/gmane.comp.compilers.llvm.devel/71881) with
an architecture he is targeting. The architecture has 64-bit registers, but
the pointer size is always 32-bits. JF Bastien suggests [this is similar to
PNaCl and the x32
ABI](http://article.gmane.org/gmane.comp.compilers.llvm.devel/71923).

* Peter Collingbourne [proposes an IR extension for loads/stores with
deterministic trap/unwind
behaviour](http://article.gmane.org/gmane.comp.compilers.llvm.devel/71773).
The aim is to support zero cost exception handling for operations that may
trap. The proposal comes with initial patches, though Andrew Trick [questions
whether adding new IR instructions is the right
approach](http://article.gmane.org/gmane.comp.compilers.llvm.devel/71934).

* The LLVM project Phabricator instance has [been moved to
reviews.llvm.org](http://article.gmane.org/gmane.comp.compilers.clang.devel/35992).
Currently links to the old one are broken, but hopefully a redirect will be
set up. By the time you read this I should have updated all broken links from
llvmweekly.org.

## LLVM commits

* MipsAsmParser and MipsOperand was rewritten. The improvements are documented
in the commit message.
[r205292](http://reviews.llvm.org/rL205292).

* The ARM backend gained support for segmented stacks.
[r205430](http://reviews.llvm.org/rL205430).

* Windows on ARM support is now possible with the MachineCode layer.
[r205459](http://reviews.llvm.org/rL205459).

* TargetLowering gained a hook to control when `BUILD_VECTOR` might be
expanded using shuffles.
[r205230](http://reviews.llvm.org/rL205230). Targets might choose to
use ExpandBVWithShuffles which was added in a later commit.
[r205243](http://reviews.llvm.org/rL205243).

* X86TargetTransformInfo gained getUnrollingPreferences, which is used by the
generic loop unroller. This helps to optimise use of the micro-op caches on
X86. This produced 7.5%-15% speedups in the TSVC benchmark suite.
[r205348](http://reviews.llvm.org/rL205348).

* ARM gained a nice little optimisation pass that removes duplicated DMB
instructions. [r205409](http://reviews.llvm.org/rL205409).

* Atomic ldrex/strex loops are now expanded in IR rather than at MachineInstr
emission time. This cleans up code, but should also make future optimisations
easier.
[r205525](http://reviews.llvm.org/rL205525).

## Clang commits

* The clang static analyzer gained double-unlock detection in
PthreadLockChecker, as well as a check for using locks after they are
destroyed. [r205274](http://reviews.llvm.org/rL205274),
[r205275](http://reviews.llvm.org/rL205275).

* The OpenMP 'copyin' clause was implemented.
[r205164](http://reviews.llvm.org/rL205164).

* The 'optnone' attribute was added, which suppresses most optimisations on a
function. [r205255](http://reviews.llvm.org/rL205255).

* The heuristics for choosing methods to suggest as corrections were improved,
to ignore methods that obviously won't work.
[r205653](http://reviews.llvm.org/rL205653).

* The 'BitwiseConstraintManager' idea was added to the open projects page.
[r205666](http://reviews.llvm.org/rL205666).

## Other project commits

* AddressSanitizer can now be used as a shared library on Linux.
[r205308](http://reviews.llvm.org/rL205308).

* compiler-rt gained support for IEEE754 quad precision comparison functions.
[r205312](http://reviews.llvm.org/rL205312).

* lld now supports `.gnu.linkonce` sections.
[r205280](http://reviews.llvm.org/rL205280).