[llvm-dev] LLVM Weekly - #111, Feb 15th 2016

[Alex Bradbury via llvm-dev]

LLVM Weekly - #111, Feb 15th 2016
=================================

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

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

There has been a [new release of the CilkPlus
compiler](http://cilkplus.github.io/). This includes an update to the latest
LLVM and Clang trunk. CilkPlus implements the Cilk Plus language extensions
for data and task parallelism in Clang.

There's been some more papers appearing from the C++ standards committee.
P0225R0, or as you may prefer to call it "[Why I want Concepts, and why I want
them sooner rather than later](https://isocpp.org/files/papers/p0225r0.html)"
is worth a read. There's also been a few [other recently published
papers](https://isocpp.org/blog/2016/02/new-papers) on iterator facades, the
filesystem technical specification, and unified function call syntax.


## On the mailing lists

* Jacques Pienaar has proposed [upstreaming the 'Lanai'
backend](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html).
This is for a CPU design used internally at Google, and the posting of these
patches did attract some [attention in the
press](http://www.theregister.co.uk/2016/02/09/google_processor/).
A good chunk of the ensuing discussion focused on what the bar should be for
accepting a new backend upstream. There seem to ultimately be far more people
for the upstreaming than against it, but some concern was raised about the
ability for others to test the generated code without access to hardware or
even simulators.

* Natanael Ramos recently worked with LLVM for his bachelor thesis, and as a
result [wrote and submitted a tutorial for writing a new LLVM register
allocator](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095083.html).
This can also be found [on
github](https://github.com/nael8r/How-To-Write-An-LLVM-Register-Allocator/blob/master/HowToWriteAnLLVMRegisterAllocator.rst).

* Nolan has been working on an [experimental 6502
backend](https://github.com/beholdnec/llvm-m6502), and sought some help with a
[memory operand folding
problem](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095379.html).
He later followed up to the list [with his
solution](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095436.html),
and David Chisnall added some [extra thoughts on potential approaches to
targeting 6502 or similar
architectures](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095439.html).

* Hans Wennborg is [looking for help in expanding the release notes for the
3.8
release](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095376.html).

* Vaivaswatha Nagaraj has been working on a [control structure
analysis](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095115.html)
capable of detecting control structures in the CFG and is seeking feedback on
his code.

* Lang Hames has followed up to his RFC on error handling in LLVM libraries
with a detailed post [summarising his thoughts and responding some some
feedback](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095324.html).

* Sadly, CMake's current Ninja generator [is
non-deterministic](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095266.html).
The good news is there is [already a fix in upstream
CMake](https://public.kitware.com/Bug/view.php?id=15968).

* Peter Collingbourne prototyped [a change to reduce DWARF emitter memory
consumption](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095306.html).
Early results are very positive.

* Philip Reames proposes [removing the inaccessiblememonly attribute from the
3.8
branch](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095290.html),
on the grounds that the major motivating patch was reverted, there has been no
further development, and including it in a release may pose a
backwards-compatibility concern. There appears to be agreement so far in the
responses.

* LLVM will be applying for inclusion in the Google Summer of Code this year.
If you have a project listed on the 'open projects' page, [please review and
update it if
necessary](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095087.html),
or suggest new projects.


## LLVM commits

* The WholeProgramDevirt pass has been added. This implements whole program
optimization of virtual calls where the list of callees is known to be fixed.
[r260312](http://reviews.llvm.org/rL260312).

* The AVR backend upstreaming continues with the addition of the AVR tablegen
instruction definitions. [r260363](http://reviews.llvm.org/rL60363).

* There's been a bunch of other work on the new global instruction selection
mechanism this week, but the commits I'd pick out are the addition of support
for translating Add instructions and for lowering returns. It is currently
being tests with the AArch64 backend.
[r260549](http://reviews.llvm.org/rL260549),
[r260562](http://reviews.llvm.org/rL260562),
[r260600](http://reviews.llvm.org/rL260600).

* The AArch64 backend gained support (including a scheduling model) for the
Qualcomm Kryo CPU. [r260686](http://reviews.llvm.org/rL260686).

* LoopUnrollAnalyzer has been abstracted out from LoopUnrollPass, and gained
unit tests for its functionality. [r260169](http://reviews.llvm.org/rL260169).

* llvm-config gained preliminary Windows support.
[r260263](http://reviews.llvm.org/rL260263).

* The details of the convergent attribute have been clarified in the language
reference. The convergent attribute will now be removed on functions which
provably don't converge or invoke any convergent functions.
[r260316](http://reviews.llvm.org/rL260318),
[r260319](http://reviews.llvm.org/rL260319).


## Clang commits

* It is now possible to perform a 3-stage Clang build using CMake. It is
suggested in the commit message this may be useful for detecting
non-determinism in the compiler by verifying stage2 and stage3 are identical.
[r260261](http://reviews.llvm.org/rL260261).

* ARMv8.2-A can be targeted using appropriate Clang options.
[r260533](http://reviews.llvm.org/rL260533).

* Clang's CMake build system learned the `CLANG_DEFAULT_CXX_STDLIB` to set the
default C++ standard library. [r260662](http://reviews.llvm.org/rL260662).


## Other project commits

* The new LLD ELF linker gained initial link-time optimisation support.
[r260726](http://reviews.llvm.org/rL260726).

* LLDB has seen some more updates for Python 3 support, though not yet enough
for a clean testsuite run. [r260721](http://reviews.llvm.org/rL260721).