Alex Bradbury via llvm-dev
2016-Feb-15 11:56 UTC
[llvm-dev] LLVM Weekly - #111, Feb 15th 2016
LLVM Weekly - #111, Feb 15th 2016 ================================ If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/111>. Welcome to the one hundred and eleventh 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. ## News and articles from around the web There has been a [new release of the CilkPlus compiler](http://cilkplus.github.io/). This includes an update to the latest LLVM and Clang trunk. CilkPlus implements the Cilk Plus language extensions for data and task parallelism in Clang. There's been some more papers appearing from the C++ standards committee. P0225R0, or as you may prefer to call it "[Why I want Concepts, and why I want them sooner rather than later](https://isocpp.org/files/papers/p0225r0.html)" is worth a read. There's also been a few [other recently published papers](https://isocpp.org/blog/2016/02/new-papers) on iterator facades, the filesystem technical specification, and unified function call syntax. ## On the mailing lists * Jacques Pienaar has proposed [upstreaming the 'Lanai' backend](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html). This is for a CPU design used internally at Google, and the posting of these patches did attract some [attention in the press](http://www.theregister.co.uk/2016/02/09/google_processor/). A good chunk of the ensuing discussion focused on what the bar should be for accepting a new backend upstream. There seem to ultimately be far more people for the upstreaming than against it, but some concern was raised about the ability for others to test the generated code without access to hardware or even simulators. * Natanael Ramos recently worked with LLVM for his bachelor thesis, and as a result [wrote and submitted a tutorial for writing a new LLVM register allocator](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095083.html). This can also be found [on github](https://github.com/nael8r/How-To-Write-An-LLVM-Register-Allocator/blob/master/HowToWriteAnLLVMRegisterAllocator.rst). * Nolan has been working on an [experimental 6502 backend](https://github.com/beholdnec/llvm-m6502), and sought some help with a [memory operand folding problem](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095379.html). He later followed up to the list [with his solution](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095436.html), and David Chisnall added some [extra thoughts on potential approaches to targeting 6502 or similar architectures](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095439.html). * Hans Wennborg is [looking for help in expanding the release notes for the 3.8 release](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095376.html). * Vaivaswatha Nagaraj has been working on a [control structure analysis](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095115.html) capable of detecting control structures in the CFG and is seeking feedback on his code. * Lang Hames has followed up to his RFC on error handling in LLVM libraries with a detailed post [summarising his thoughts and responding some some feedback](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095324.html). * Sadly, CMake's current Ninja generator [is non-deterministic](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095266.html). The good news is there is [already a fix in upstream CMake](https://public.kitware.com/Bug/view.php?id=15968). * Peter Collingbourne prototyped [a change to reduce DWARF emitter memory consumption](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095306.html). Early results are very positive. * Philip Reames proposes [removing the inaccessiblememonly attribute from the 3.8 branch](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095290.html), on the grounds that the major motivating patch was reverted, there has been no further development, and including it in a release may pose a backwards-compatibility concern. There appears to be agreement so far in the responses. * LLVM will be applying for inclusion in the Google Summer of Code this year. If you have a project listed on the 'open projects' page, [please review and update it if necessary](http://lists.llvm.org/pipermail/llvm-dev/2016-February/095087.html), or suggest new projects. ## LLVM commits * The WholeProgramDevirt pass has been added. This implements whole program optimization of virtual calls where the list of callees is known to be fixed. [r260312](http://reviews.llvm.org/rL260312). * The AVR backend upstreaming continues with the addition of the AVR tablegen instruction definitions. [r260363](http://reviews.llvm.org/rL60363). * There's been a bunch of other work on the new global instruction selection mechanism this week, but the commits I'd pick out are the addition of support for translating Add instructions and for lowering returns. It is currently being tests with the AArch64 backend. [r260549](http://reviews.llvm.org/rL260549), [r260562](http://reviews.llvm.org/rL260562), [r260600](http://reviews.llvm.org/rL260600). * The AArch64 backend gained support (including a scheduling model) for the Qualcomm Kryo CPU. [r260686](http://reviews.llvm.org/rL260686). * LoopUnrollAnalyzer has been abstracted out from LoopUnrollPass, and gained unit tests for its functionality. [r260169](http://reviews.llvm.org/rL260169). * llvm-config gained preliminary Windows support. [r260263](http://reviews.llvm.org/rL260263). * The details of the convergent attribute have been clarified in the language reference. The convergent attribute will now be removed on functions which provably don't converge or invoke any convergent functions. [r260316](http://reviews.llvm.org/rL260318), [r260319](http://reviews.llvm.org/rL260319). ## Clang commits * It is now possible to perform a 3-stage Clang build using CMake. It is suggested in the commit message this may be useful for detecting non-determinism in the compiler by verifying stage2 and stage3 are identical. [r260261](http://reviews.llvm.org/rL260261). * ARMv8.2-A can be targeted using appropriate Clang options. [r260533](http://reviews.llvm.org/rL260533). * Clang's CMake build system learned the `CLANG_DEFAULT_CXX_STDLIB` to set the default C++ standard library. [r260662](http://reviews.llvm.org/rL260662). ## Other project commits * The new LLD ELF linker gained initial link-time optimisation support. [r260726](http://reviews.llvm.org/rL260726). * LLDB has seen some more updates for Python 3 support, though not yet enough for a clean testsuite run. [r260721](http://reviews.llvm.org/rL260721).