Alex Bradbury via llvm-dev
2016-May-09 08:24 UTC
[llvm-dev] LLVM Weekly - #123, May 9th 2016
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).