LLVM Weekly - #103, Dec 21st 2015
Welcome to the one hundred and 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 firstname.lastname@example.org, or @llvmweekly or @asbradbury on Twitter.
The canonical home for this issue can be found here at llvmweekly.org.
Regular readers will know about lowRISC, a not-for-profit project a group of us founded aiming to produce a complete open-source System-on-Chip in volume. We've just hit a new milestone with the untethering of the base SoC. If you're interested in contributing, the blog post contains a number of potential starting points.
News and articles from around the web
The 6th EuroLLVM conference will be held on March 17th-18th in Barcelona, Spain. The call for papers is now open and will remain open until January 25th 2016. EuroLLVM CFP
Chandler Carruth's keynote, "Understanding compiler optimizations" from the Meeting C++ 2015 conference is now online.
Richard Pennington has blogged about bootstrapping LLVM and Clang using pre-compiled ELLCC binaries.
Bloomberg is going to be holding a weekend Clang and LLVM hackathon in NYC and in London on February 6th and 7th. The event will be open to everyone in the community and Bloomberg will provide space, power, food, beverages, and internet access.They're looking for experienced Clang and LLVM developers to help as mentors.
On the mailing lists
Marshall Clow proposes dropping support in libc++ for GCC versions prior to 4.7. Eric Fiselier suggests that actually GCC 4.7 and 4.8 have a rather large number of test failures and 4.9 would be a more sensible requirement.
Dmitry Polukhin has proposed an RFC on supporting GCC's ifunc attribute. He proposes three potential approaches and feedback so far prefers the second.
Easwaran Raman has posted an RFC on hotness thresholds in profile-guided optimisation. The proposal attempts to define a way of determining hot blocks that works both for programs with few hot-spots and a long tail of frequently executed blocks.
LLVM IR now supports floating point atomic loads and stores. r255737.
New attributes have been introduced:
InaccessibleMemOnly(a function may only access memory that is not accessible by the module being compiled) and
InaccessibleMemOrArgMemOnly(a function may only access memory that is either not accessible by the module being compiled or is pointed to by its pointer arguments). r255778.
The PowerPC backend gained support for soft float operations on ppc32. r255516.
terminatepadinstruction has been removed from LLVM IR. r255522.
IR call instructions can now take a fast-math flags marker which indicates fast-math flags may allow otherwise unsafe optimisations. r255555.
LLVM gained a C++11 ThreadPool in its internal library. It is intended to be used for ThinLTO. r255593.
The default set of passes has been adjusted. mem2reg will not be run immediately after globalopt and more scalar optimization passes have been added to the LTO pipeline. r255634.
The llvm-profdata tool now supports specifying a weight when merging profile data. This can be used to give more relative importance to one of multiple profile runs. r255659.
For CMake builds, a
compile_commands.jsonfile will now be generated which tells tools like YouCompleteMe and
clang_completehow to build each source file. r255789.
The Hexagon VLIW packetizer saw a large update (though unfortunately the changes aren't summarised in the commit message). r255807.
A number of LLVM's C APIs have been depreciated: LLVMParseBitcode, LLVMParseBitcodeInContext, LLVMGetBitcodeModuleInContext and LLVMGetBitcodeModule. These have been replaced with new versions of the functions which don't record a diagnostic. r256065.
The AVR backend (which is being imported incrementally) gained AVR.td and AVRRegisterInfo.td. r256120.
A new checker has been introduced to detect excess padding in classes and structs. r255545.
A new control-flow integrity mode was introduced, cross-DSO CFI allows control flow to be protected across shared objects. It is currently marked experimental. r255694.