[llvm-dev] LLVM Weekly - #123, May 9th 2016

[Alex Bradbury via llvm-dev]

LLVM Weekly - #123, May 9th 2016
================================

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

Welcome to the one hundred and twenty-third 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.

If you're in London tomorrow you may be interested in the [NMI Open Source
Conference](http://oshug.org/event/nmiopen). You can register until midday
today. I'll be giving a brief talk on [lowRISC](http://www.lowrisc.org/).
While on the subject of conferences, if you are interested in diversity and
inclusion in computing education, you may want to check out the [CAS #include
diversity conference](http://casinclude.org.uk/events/diversity-conference-2016/)
in Manchester on the 11th June.


## News and articles from around the web

Fabien Giesen has written a brief article explaining [why compilers exploit
undefined signed
overflow](https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759de5a7).

The Google Open Source blog has a [short
piece](http://google-opensource.blogspot.co.uk/2016/05/xray-function-call-tracing-system.html)
on the XRay function call tracing system that was proposed for upstreaming
last week on the LLVM mailing list.


## On the mailing lists

* By far the most active thread on the mailing list this week was the
[resumption of discussion on adding an LLVM Code of
Conduct](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html). The
draft text can be found [here](http://reviews.llvm.org/D13741). As well as a
number of messages offering a "+1" to the current text, concerns were raised
by some about the implications of "violations of this code outside these
spaces may affect a person's ability to participate within them", and about
how the committee enforcing the CoC will be selected.

* Amos Robinson wrote to the mailing list with [an optimisation missed by
LLVM's current Global Value Numbering
pass](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099034.html). Rather
excitingly, Daniel Berlin
[reports](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099035.html) he's
working on a [new GVN
implementation](https://github.com/dberlin/llvm-gvn-rewrite/branches).

* Chandler Carruth has written an update on the [state of work to move to the
new pass
manager](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099121.html). He
notes the major missing piece at the moment is the ability to communicate
invalidation information between two parts of the pass manager.

* Jonas Hahnfield has shared an RFC on [automatically generating non-temporal
loads and
stores](http://lists.llvm.org/pipermail/llvm-dev/2016-May/098980.html). Some
respondents are very strongly against this, suggesting it's something better
left for the programmer to specify.

* Some of the students taking part in Google Summer of Code this year with
LLVM-related projects have been introducing themselves on the mailing list.
Utpal Bora will be working on [implementing Polly as an analysis pass in
LLVM](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099373.html).
Bianca-Cristina Cristescu will be working in [enabling LLVM's self-hosted
modules builds using
libstdc++](http://lists.llvm.org/pipermail/cfe-dev/2016-May/048671.html), and
Roman Gareev will be [improving the vectorisation process in
Polly](http://lists.llvm.org/pipermail/llvm-dev/2016-May/098943.html).

* Chris Bieneman notes he recently introduced a new option in LLVM's CMake
buildsystem that may be of particular interest to package maintainers.
[LLVM_DISTRIBUTION_COMPONENTS](http://lists.llvm.org/pipermail/llvm-dev/2016-May/098993.html)
allows you to specify which components of LLVM you want to install.

* Peter Collingbourne has posted an RFC on [extending ThinLTO to allow a
bitcode module to embed another bitcode module containing summary information
for CFI and whole-program
devirtualisation](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099095.html).

* Adam Nemet is interested in feedback on the idea of [filtering optimisation
remarks by the hotness of the code
region](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099082.html).

* Justin Bogner has given a heads-up to out-of-tree backend maintainers that
he [intends to change the API of
SelectionDAGISel::Select](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099216.html)
so the function directly replaces nodes rather than returning the desired
replacement.

* Quentin Colombet has shared an RFC on [how LLVM contributors can better help
release
management](http://lists.llvm.org/pipermail/llvm-dev/2016-May/098952.html).
There's a lot of support for this direction, with most comments discussing
ways of better tagging commit messages (post-commit in phabricator/bugzilla,
or through getting committers to write commit messages in a certain format).


## LLVM commits

* LLVM's CppBackend has been removed. As the commit message says, this backend
has bit-rotted to the extent that it's not useful for its original purpose and
doesn't generate code that compiles.
[r268631](http://reviews.llvm.org/rL268631).

* The AVR backend has seen a large amount of code merged in to LLVM.
[r268722](http://reviews.llvm.org/rL268722).

* The MIPS backend has seen some large changes to how relocations are handled.
These are now represented using MipsMCExpr instead of MCSymbolRefExpr. As
someone who has done quite a lot of (out-of-tree) LLVM backend work, I've
always found it odd how some architectures have globally visible enum members
in include/llvm/MC/MCExpr.h. [r268379](http://reviews.llvm.org/rL268379).

* LLVM builds should hopefully now be deterministic by default, as
`LLVM_ENABLE_TIMESTAMPS` is now opt-in rather than opt-out. In fact, a
follow-up patch removed the option altogether.
[r268441](http://reviews.llvm.org/rL268441),
[r268670](http://reviews.llvm.org/rL268670).

* The AArch64 backend learned to combine adjustments to the stack pointer for
callee-save stack memory and local stack memory.
[r268746](http://reviews.llvm.org/rL268746).


## Clang commits

* Clang now supports `-malign-double` for x86. This matches the default
behaviour on x86-64, where i64 and f64 types are aligned to 8-bytes
instead of 4.
[r268473](http://reviews.llvm.org/rL268473).

* Loop unrolling is no longer completely disabled for `-Os`.
[r268509](http://reviews.llvm.org/rL268509).

* Clang's release notes (reflecting the state of current trunk) have been
updated to say more about the state of C++1z support.
[r268663](http://reviews.llvm.org/rL268663).


## Other project commits

* libcxx will now build a libc++experimental.a static library to hold symbols
from the experimental C++ Technical Specifications (e.g. filesystem). This
library provides no ABI compatibility.
[r268443](http://reviews.llvm.org/rL268443),
[r268456](http://reviews.llvm.org/rL268456).

* All usage of pthreads in libcxx has been refactored in to the
`__threading_support` header, with the intention of making it easier to
retarget libcxx to platform that don't support pthreads.
[r268374](http://reviews.llvm.org/rL268374).

* libcxx gained support for the [polymorphic memory
resources](https://isocpp.org/files/papers/N3916.pdf) C++ TS.
[r268829](http://reviews.llvm.org/rL268829).