[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
in Manchester on the 11th June.
## News and articles from around the web
Fabien Giesen has written a brief article explaining [why compilers exploit
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
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
excitingly, Daniel Berlin
working on a [new GVN
* Chandler Carruth has written an update on the [state of work to move to the
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
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
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