LLVM Weekly - #108, Jan 25th 2016
Welcome to the one hundred and eighth 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 email@example.com, or @llvmweekly or @asbradbury on Twitter.
The canonical home for this issue can be found here at llvmweekly.org.
News and articles from around the web
LLVM 3.8 RC1 has been released. Now is the time to test it out with your favourite projects and report any issues.
The deadline for the EuroLLVM call for papers is today.
Version 1.6 of the Rust programming language was released las week. Rust uses LLVM for its code generation.
The LLVM Social in Paris will be held this week on Wednesday.
On the mailing lists
Quentin Colombet has posted an RFC asking for views on adding a kind of MachineModulePass. Questions include who would be interested and why. John Criswell's response includes some interesting use-cases.
Eduard-Mihai Burtescu has posted an RFC on making byval argument passing work with opaque pointers.
Quentin Colombet has posted an RFC seeking opinions on the contract between LLVM IR and the backends for instruction selection. In particular, should backends be able to perform instruction selection on any valid LLVM IR. Several people have fed back that in practical terms, a backend doesn't need to be able to select any instruction as long as it provides IR to IR transformations that can perform necessary modifications prior to instruction selection.
Jonas Wagner is looking for feedback on how to support self-modifying branches in LLVM. The thread contained some interesting discussion about the cost of well-predicted branches. It would certainly seem worthwhile to delve deeper to see how much of the overhead is due to limitations in LLVM's basic block at-a-time instruction scheduler.
Philip Reames has written to the list to warn users of the RewriteStatePointsForGC that there are currently issues expressing arbitrary exceptional control flow. The thread discusses some potential solutions to the current issues.
Ed Maste has been working to use libunwind in FreeBSD's base system, and queries its stack usage. LLVM's libunwind allows for 120 saved registers on all architectures, while in contrast the GCC unwinder has a target-dependent maximum (it's 18 on x86-64).
llvm::SplitModulegained a new flag which can be used to cause it to attempt to split the module without globalizing local objects. r258083.
The WebAssembly backend will now rematerialize constants with multiple uses rather than holding them live in registers, as there is no code size saving in using registers in for constants in most cases in the WebAssembly encoding. r258142.
Some small patches from the global instruction selection effort have started to land, such as the introduction of a generic machine opcode for ADD (
G_ADD) and the all-important CMake support for building it. r258333, r258344.
getCacheLineSizewas added to TargetTransformInfo. It's currently only used by PPCLoopDataPrefetch. r258419.
LoopIdiomRecognize improved in its ability to recognise memsets. r258620.
The LeakSanitizer documentation has been updated with a usage example. r258476.