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

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Mon May 9 01:24:28 PDT 2016

LLVM Weekly - #123, May 9th 2016

If you prefer, you can read a HTML version of this email at

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

The Google Open Source blog has a [short
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

* 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
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

* Chris Bieneman notes he recently introduced a new option in LLVM's CMake
buildsystem that may be of particular interest to package maintainers.
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

* Adam Nemet is interested in feedback on the idea of [filtering optimisation
remarks by the hotness of the code

* Justin Bogner has given a heads-up to out-of-tree backend maintainers that
he [intends to change the API of
so the function directly replaces nodes rather than returning the desired

* Quentin Colombet has shared an RFC on [how LLVM contributors can better help
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.

* The AVR backend has seen a large amount of code merged in to LLVM.

* 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.

* The AArch64 backend learned to combine adjustments to the stack pointer for
callee-save stack memory and local stack memory.

## 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.

* Loop unrolling is no longer completely disabled for `-Os`.

* Clang's release notes (reflecting the state of current trunk) have been
updated to say more about the state of C++1z support.

## 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.

* 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.

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

More information about the llvm-dev mailing list