[LLVMdev] LLVM Weekly - #4, Jan 27th 2014

[Alex Bradbury]

LLVM Weekly - #4, Jan 27th 2014
===============================

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

Welcome to the fourth issue of LLVM Weekly, a weekly newsletter (published
every Monday) covering developments in LLVM, Clang, and related projects. This
marks the end of the first month of operation, here's to many more! 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. I've been
keeping the [@llvmweekly Twitter account](https://twitter.com/llvmweekly)
updated throughout the week, so follow that if you want more frequent news
updates.

## News and articles from around the web

The biggest compiler-related news this week has been the discussions on the
GCC mailing list. Things kicked off with [Eric S. Raymond's
post](http://gcc.gnu.org/ml/gcc/2014-01/msg00176.html) suggesting that
technical progress in GCC is being held back by concerns about reusing parts
of GCC in a way that bypasses the copyleft license. Ian Lance Taylor
[responded](http://gcc.gnu.org/ml/gcc/2014-01/msg00181.html) to point out that
GCC now has a plugin system, albeit with an unstable interface, which mostly
put a stop to that line of discussion. However a [later post to the mailing
list from Richard Stallman](http://gcc.gnu.org/ml/gcc/2014-01/msg00247.html)
has proved very controversial by claiming that "The existence of LLVM is
a terrible setback for our community precisely because it is not
copylefted and can be used as the basis for nonfree compilers". There's plenty
of discussion of these comments around the web [at
LWN](http://lwn.net/Articles/582242/), Hacker News, Reddit, Slashdot etc.
Although many of us may have a preference for non-copyleft ('permissive') free
software licenses, RMS has consistently and over a long period of time argued
that copyleft licenses ultimately do a better job of spreading free software
and preserving its freedom. As such, it's not clear to me why this mailing
list post has come as a surprise to many. I'm personally surprised he didn't
bring up the fact that the BSD-style license used by LLVM contains no explicit
patent grant (though LLVM does have a [patent
policy](http://llvm.org/docs/DeveloperPolicy.html#patents) to help protect its
users).

Rapidly moving away from controversial topics, an exciting milestone for the
LLVM project was hit this week. The [200000th commit](http://t.co/IjK2VOcGOq)
has been applied. Takumi Nakamura was lucky enough to be the one to author
that commit.

The Khronos group has [released the SPIR 1.2
specification](https://www.khronos.org/news/press/khronos-releases-spir-1.2-specification-for-portable-encoding-of-opencl-dev).
SPIR is a standardised intermediate representation meant for use with OpenCL,
and is based on LLVM 3.2 IR. With the release, the Khronos Group have open
sourced a modified Clang 3.2 which can generate SPIR from OpenCL C programs as
well as a module verifier.

Joaquín M López Muñoz has published a benchmark [comparing hash table
performance on
Clang](http://bannalia.blogspot.co.uk/2014/01/a-better-hash-table-clang.html).
He compares GCC's libstdc++-v3 to the LLVM project's libc++.

The Cambridge (UK) LLVM socials [are starting up
again](http://article.gmane.org/gmane.comp.compilers.clang.devel/34548), with
the next one on the 29th Jan at 7.30pm. Sadly I can't make it, hopefully the
next one!

## On the mailing lists

* Chandler Carruth asks [whether LoopPass and LoopPassManager can be
removed](http://article.gmane.org/gmane.comp.compilers.llvm.devel/69689). He
lists the confusion and issues they cause, most damning to me is that they
reoutinely modify IR from outside of the loop thus breaking the implied
contract of a 'loop pass'. The discussion ended up with the proposal that
LoopSimplify, LCSSA, and LoopVectorizer become function passes. As you can see
from the LLVM commit section below, Chandler quickly submitted patches to do
this which have been applied.

* Vadim asks for input on his idea of [using LLVM to generate code with
position-independent
stacks](http://article.gmane.org/gmane.comp.compilers.llvm.devel/69727). This
would be usual for implementing something similar to Python greenlets. Mark
Seaborn points to [some similar
work](https://codereview.chromium.org/29743003/) he has done which restricts
memory access to a range of address space.

* Tom Stellard has completed a [suggested policy and process for LLVM minor
releases](http://article.gmane.org/gmane.comp.compilers.llvm.devel/69778).

* Shea Levy, a maintainer for nixpkgs writes to the list with [the issues he
has
encountered](http://article.gmane.org/gmane.comp.compilers.llvm.devel/69662)
packaging LLVM and Clang for Nix.

* Raul Silvera [asks for opinions on removing the ReadOnly attribute from math
intrinsics](http://article.gmane.org/gmane.comp.compilers.llvm.devel/69781) on
the grounds that changes to the floating point environment (such as rounding
mode) aren't modelled anyway. As Raul points out in a later followup "We
currently appear to be at the worst of both worlds as we do not have support
for this environment but are always being constrained by it."

* Sebastien Riou asks [how to force a MachineFunctionPass to be the last
one](http://article.gmane.org/gmane.comp.compilers.llvm.devel/69670). Peter
Cooper suggests that at the moment you can add the pass to the end of
`X86PassConfig::addPreEmitPass` or add the pass after the call to preEmitBass
and before the ASM printer is added.

* Jasper Neumann has spotted various cases where [LLVM leaves unnecessary
register moves](http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69601)
in the generated code. Andrew Trick suggests copy-eliminating peepholes could
be added after register allocation, but that in general there is reluctance to
introduce extra complexity to optimise special cases involving multiple
physical register copies due to the small impact they have on performance.

* David Chisnall enquires whether [LLVM relies on the assumption that the
stack is in address space
0](http://article.gmane.org/gmane.comp.compilers.llvm.devel/69711). Matt
Arsenault notes that OpenCL local variables currently work by created globals
rather than alloca'ing a nondefault address space. He suggests the limitation
stems from the fact a number of places in the compiler assume the address
space is 0 and never check by retrieving the address space of the relevant
pointer.

* Christian Schafmeister has posted [a preannouncement of his
soon-to-be-released C++ refactoring
tool](http://article.gmane.org/gmane.comp.compilers.clang.devel/34505),
written in Lisp. It makes use of clang's ASTMatcher/Refactoring library. I'm
looking forward to the promised open source release.

* David Fang has posted a [summary of the status of libc++ on
powerpc-darwin](http://article.gmane.org/gmane.comp.compilers.clang.devel/34507).

## LLVM commits

* LoopSimplify is no longer a LoopPass, instead it is both a utility function
and a FunctionPass. The motivation was to be able to compute function analysis
passes after running LoopSimplify, but the change has a bunch of other
advantages described in detail in the commit message.
[r199884](http://llvm-reviews.chandlerc.com/rL199884). Additionally, the LCSSA
(loop-closed SSA) pass was made a utility with a function pass and the
LoopVectorizer became a FunctionPass.
[r200067](http://llvm-reviews.chandlerc.com/rL200067),
[r200074](http://llvm-reviews.chandlerc.com/rL200074).

* The Constant Hoisting Pass was born.
[r200022](http://llvm-reviews.chandlerc.com/rL200022).

* InstCombine learned how to deal with vectors for most
fmul/fvid/add/sub/mul/div combines.
[r199598](http://llvm-reviews.chandlerc.com/rL199598),
[r199602](http://llvm-reviews.chandlerc.com/rL199602).

* Type-based alias analysis has, for the time being, been disabled when using
alias analysis in CodeGen due to two shortcomings described in the commit
message. [r200093](http://llvm-reviews.chandlerc.com/rL200093).

* LTO gained new methods which allows the user to parse metadata nodes,
extract linker options, and extract dependent libraries from a bitcode module.
[r199759](http://llvm-reviews.chandlerc.com/rL199759).

* The Sparc backend now supports the inline assembly constraint 'I'.
[r199781](http://llvm-reviews.chandlerc.com/rL199781).

* The x86 backend allows segment and address-size overrides for
movs/lods/outs, fixing [bug 9385](http://llvm.org/bugs/show_bug.cgi?id=9385).
[r199803](http://llvm-reviews.chandlerc.com/rL199803) and more.

* llvm-ar no longer opens or fstats file twice.
[r199815](http://llvm-reviews.chandlerc.com/rL199815).

* When compiling a function with the minsize attribute, the ARM backend will
now use literal pools even for normal i32 immediates.
[r199891](http://llvm-reviews.chandlerc.com/rL199891).

* There was a fair bit of activity on the R600 backend. I haven't had the time
to properly summarise that activity or pick out the most important commits, so
I recommend those interested take a look through the commit logs.

* JIT is now supported for Sparc64.
[r199977](http://llvm-reviews.chandlerc.com/rL199977).

* llvm-readobj gained support for the PE32+ format (used for Windows 64-bit
executables). [r200117](http://llvm-reviews.chandlerc.com/rL200117).

## Clang commits

* Registry::getCompletions was implemented. This returns a list of valid
completions for a given context.
[r199950](http://llvm-reviews.chandlerc.com/rL199950).

* Clang gained basic support for the attribute `returns_nonnull`.
[r199626](http://llvm-reviews.chandlerc.com/rL199626),
[r199790](http://llvm-reviews.chandlerc.com/rL199790).

* getResultType on function and method declarations was renamed to
getReturnType which is a semantically more accurate name.
[r200082](http://llvm-reviews.chandlerc.com/rL200082). Similarly, getResultLoc
was renamed to getReturnLoc.
[r200105](http://llvm-reviews.chandlerc.com/rL200105).

* All applicable accessors in FunctionProtoType have been renamed from
`*argument*` to `*parameter*`.
[r199686](http://llvm-reviews.chandlerc.com/rL199686).

* Clang was taught to look in its installation libdir for libraries such as
libc++ when the installation is within the system root.
[r199769](http://llvm-reviews.chandlerc.com/rL199769).

* A module.map file is now required to load a module.
[r199852](http://llvm-reviews.chandlerc.com/rL199852).

## Other project commits

* lldb learned the 'step-avoid-libraries' setting, which allows a user to list
libraries to avoid. [r199943](http://llvm-reviews.chandlerc.com/rL199943).

* In compiler-rt, support was added for intercepting and sanitizing arguments
passed to printf functions in AddressSanitizer and ThreadSanitizer.
[r199729](http://llvm-reviews.chandlerc.com/rL1999729).

* A fix was committed to ThreadSanitizer to prevent deadlocking after a fork.
[r199993](http://llvm-reviews.chandlerc.com/rL1999993).

* Dragonegg can now be built with CMake.
[r199994](http://llvm-reviews.chandlerc.com/rL199994).

* Compiler-rt gained support in its udiv/umod implementations for ARMv4 which
lacks bx and clz. Code changes also resulting in a 30%+ performance
improvement on the Raspberry Pi (armv7, ARM1176) and 5-10% on a Cortex A9.
[r200001](http://llvm-reviews.chandlerc.com/rL200001).

* In AddressSanitizer on Android, all AddressSanitizer output is duplicated to
the system log. [r199887](http://llvm-reviews.chandlerc.com/rL1999887).

* lld gained support for emitting a PE32+ file header.
[r200128](http://llvm-reviews.chandlerc.com/rL200128).

* lldb now supports Haswell on x86-64.
[r199854](http://llvm-reviews.chandlerc.com/rL199854).