LLVM Weekly - #123, May 9th 2016

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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

If you're in London tomorrow you may be interested in the NMI Open Source Conference. You can register until midday today. I'll be giving a brief talk on lowRISC. 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 in Manchester on the 11th June.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Fabien Giesen has written a brief article explaining why compilers exploit undefined signed overflow.

The Google Open Source blog has a short piece 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. The draft text can be found here. 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. Rather excitingly, Daniel Berlin reports he's working on a new GVN implementation.

• Chandler Carruth has written an update on the state of work to move to the new pass manager. 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. 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. Bianca-Cristina Cristescu will be working in enabling LLVM's self-hosted modules builds using libstdc++, and Roman Gareev will be improving the vectorisation process in Polly.

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

• Adam Nemet is interested in feedback on the idea of filtering optimisation remarks by the hotness of the code region.

• Justin Bogner has given a heads-up to out-of-tree backend maintainers that he intends to change the API of SelectionDAGISel::Select 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. 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.

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

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

• 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, r268670.

• The AARch64 backend learned to combine adjustments to the stack pointer for callee-save stack memory and local stack memory. r268746.

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.

• Loop unrolling is no longer completely disabled for -Os. r268509.

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

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, r268456.

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

• libcxx gained support for the polymorphic memory resources C++ TS. r268829.