[LLVMdev] LLVM Weekly - #38, Sep 22nd 2014

[Alex Bradbury]

LLVM Weekly - #38, Sep 22nd 2014
================================

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

Welcome to the thirty-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](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 at PyConUK this past weekend so I'm afraid it's another slightly
shorter than normal issue. I've been talking about
[Pyland](http://www.pyland.org), a programming game that aims to teach
children programming in Python (and of course, runs on Raspberry Pi).


## News and articles from around the web

A paper has recently been published about
[Harmony](http://arcade.cs.columbia.edu/harmony). In the words of the authors
"Harmony is an open source tool (built as an LLVM pass) that creates a new
kind of application profile called Parallel Block Vectors, or PBVs. PBVs track
dynamic program parallelism at basic block granularity to expose opportunities
for improving hardware design and software performance." Their most recent
[paper on ParaShares](http://arcade.cs.columbia.edu/parashares-europar14.pdf)
describes how they find the most 'important' basic blocks in multithreaded
programs.

Richard Pennington has written up [some more thoughts on cross compilation
configuration for Clang](http://ellcc.org/blog/?p=13246).

[Clike](https://github.com/combinatorylogic/clike) is a low-level programming
language with an extensible syntax based on C. It of course targets LLVM.

If you want your Emacs editor to automatically disassemble LLVM bitcode inside
Emacs buffers, then
[autodisass-llvm-bitcode](https://github.com/gbalats/autodisass-llvm-bitcode)
is for you.


## On the mailing lists

* Stephen Wu has published an RFC regarding [exhaustive bitcode compatibility
tests for IR
features](http://article.gmane.org/gmane.comp.compilers.llvm.devel/77010). The
proposal involves testing every existing IR feature so that backward
compatibility can be tested and it will become obvious when it is broken
inadvertently.

* If you're wondering about the current status of compiling glibc with
Clang/LLVM, Kostya Serebryany [has the
answer](http://article.gmane.org/gmane.comp.compilers.llvm.devel/77025). There
are about ten instances of nested functions and four of VLAIS, with some
patches waiting to be reviewed by upstream.

* Daniel Stewart has [suggested postponing various passes to the linking stage
when using
LTO](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76915). There's
agreement on this, suggesting that vectorisation and inlining should be
delayed.

* Christophe Duvernois [asks whether LLVM link against miniz rather than
zlib](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76887). If
you're interested in a long discussion about the disadvantages of checking in
dependencies locally to a codebase, this is the thread for you.


## LLVM commits

* The LLVM MC layer can now write BigObj-style COFF object files.
[r217812](http://reviews.llvm.org/rL217812).

* X86AtomicExpandPass has been removed in favour of using the generic
AtomicExpandHooks (which now has the necessary hooks).
[r217928](http://reviews.llvm.org/rL217928).

* llvm-cov's internal API has been reworked.
[r217975](http://reviews.llvm.org/rL217975).


## Clang commits

* Clang can now use 'response files' when calling other tools when the length
of the command line exceeds system limits.
[r217792](http://reviews.llvm.org/rL217792).

* The `-Wbind-to-temporary-copy` warning is no longer on by default.
[r218008](http://reviews.llvm.org/rL218008).

* Clang's thread safety analysis gained `-Wthread-safety-reference` which
warns when a guarded variable is passed by reference as a function argument.
[r218087](http://reviews.llvm.org/rL218087).


## Other project commits

* libcxx gained some support for using newlib as its C library.
[r218144](http://reviews.llvm.org/rL218144).