Welcome to the fifty-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 email@example.com, or @llvmweekly or @asbradbury on Twitter.
I'm going to be in California next week for the RISC-V workshop. I'm arriving at SFO on Monday 12th and leaving on Sunday the 18th. Do let me know if you want to meet and talk lowRISC/RISC-V or LLVM, and we'll see what we can do.
The canonical home for this issue can be found here at llvmweekly.org.
News and articles from around the web
I was getting ready to break out gitstats for some analysis of the LLVM repo and I find to my delight that Phoronix has saved me the trouble and has shared some stats on activity in the LLVM repo over the past year.
Tom Stellard has made a blog post announcing some recent RadeonSI performance improvements on his LLVM development branch. This includes 60% improvement in one OpenCL benchmark and 10-25% in a range of other OpenCL tests.
Gaëtan Lehmann has written a blog post about getting started with libclang using the Python bindings.
The C++ Filesystem Technical Specification, based on the Boost.Filesystem library has been approved.
On the mailing lists
Virgile Bello has some questions on how he can control the calling convention in LLVM. In this case, he has an CLR frontend and is trying to pass an object on the CLR stack to a native Win32 function. Reid Kleckner suggests the best way may be to just link with Clang and use its implementation. In another followup, he links to the talk on this topic at the last LLVM dev meeting.
Is anybody using the ModuleBuilder class in Clang?. If so, now is the time to speak up as it's slated to be removed.
The release of LLVM/Clang 3.5.1 may be slightly delayed due to the addition of new patches late in the process. Chandler Carruth points out that there are some unpleasant bugs in InstCombine in the current 3.5.1 release candidate. If there is a release candidate 3, the patch in question will definitely make it in.
Instruction selection for bit-permuting operations on PowerPC has been improved. r225056.
The scalar replacement of aggregates (SROA) pass has started to learn how to more intelligently handle split loads and stores. As explained in detail in the commit message, the old approach lead to complex IR that can be difficult for the optimizer to work with. SROA is now also more aggressive in its splitting of loads. r225061, r225074.
InstCombine will now try to transform
A-B < 0in to
A < B. r225034.
- More crash bugs have been uncovered and fixed by the naive fuzzing technique previously covered in LLVM Weekly. e.g. r224915.