Alex Bradbury via llvm-dev
2016-Sep-26 11:54 UTC
[llvm-dev] LLVM Weekly - #143, Sep 26th 2016
LLVM Weekly - #143, Sep 26th 2016 ================================ If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/143>. Welcome to the one hundred and forty-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](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 Slides and videos are now [available](http://llvm.org/devmtg/2016-09/#schedule) from the LLVM Cauldron 2016, which was recently held in Hebden Bridge (UK). A massive thank you to all attendees, speakers, helpers, and sponsors for making the event such a success. A special thanks are due to Simon Cook of Embecosm for handling the video recording (who as you may recall from a previous LLVM Weekly, got the videos online within a few days). Slides and videos are also [available](https://gcc.gnu.org/wiki/cauldron2016#Slides.2C_Videos_and_Notes) from the GNU Tools Cauldron. There was, as you would hope, a large overlap between attendees at the LLVM and GNU events and the joint social event also helped encourage mixing. I hope we'll be able to do something similar next year (i.e. co-located with the GNU Tools Cauldron, and with no fee for attendance). Sanjoy Das has written up a blog post about [how integer overflow fits in with LLVM's ScalarEvolution](http://www.playingwithpointers.com/scev-integer-overflow.html). The APOLLO runtime-speculative polyhedral loop optimiser and parallelizer has been [released](http://lists.llvm.org/pipermail/llvm-dev/2016-September/104997.html). As explained on the [project's homepage](http://apollo.gforge.inria.fr/about), the framework allows a user to mark nested loops to be handled by a speculative parallelization process. Clang UPC 3.8.1-0 has been [released](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105100.html). The Clang UPC project provides a compiler and execution environment for programs written in the Unified Parallel C language. It also includes a UPC to C translator. The next LLVM social in Berlin will be [taking place](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105145.html) on Thursday 29th September at 7pm at the offices of Ableton. Slides from the recent [CppCon](https://cppcon2016.sched.org/) are starting to [appear on GitHub](https://github.com/CppCon/CppCon2016). Videos are also starting to be uploaded to the [CppCon YouTube channel](https://www.youtube.com/playlist?list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH). ## On the mailing lists * Serge Pavlov [proposes that Clang support configuration files](http://lists.llvm.org/pipermail/cfe-dev/2016-September/050776.html) that allows specifying options that would otherwise be passed on the command-line. Renato Golin moved the discussion towards [how this could be used in cross-compilation toolchains](http://lists.llvm.org/pipermail/cfe-dev/2016-September/050778.html), and Richard Pennington dropped by to explain [the solution he uses for ellcc](http://lists.llvm.org/pipermail/cfe-dev/2016-September/050783.html). * Krzysztof Parzyszek has shared an RFC on supporting [variable-sized register classes](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105027.html). This is perhaps best understood by examining the motivation. Right now in-tree targets like MIPS and Hexagon have instructions that have multiple definitions in tablegen that are repeated for different register sizes. For instance, in MIPS [OR](https://github.com/llvm-mirror/llvm/blob/ffabbc5291d4fdf12a6cadc9f19dc0fdade2a68d/lib/Target/Mips/MipsInstrInfo.td#L1748) and [OR64](https://github.com/llvm-mirror/llvm/blob/39b3d8a9d4a288ce9e8233b892ca9f31afdfbe42/lib/Target/Mips/Mips64InstrInfo.td#L133). These instructions have the same encoding but need multiple definitions as they operate on different register sizes depending on if the machine is 32-bit or 64-bit. In this proposal, there would be a 'HwMode' which is determined from SubtargetInfo and this mode will determine the register size, spill size, spill alignment and valid types for a given RegisterClass. With the RISC-V backend work I'm upstreaming I'm keen to avoid duplicating definitions of the whole base instruction set across RV32, RV64 and potentially RV128, os discussed [here](https://reviews.llvm.org/D23561) trialled using a multiclass definition to parameterise the whole instruction set. Krzystof's proposal requires changes to TableGen, but should be simpler for the backend writer. A [later follow-up](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105152.html) helps to clarify how it works. More input on the idea is needed, particularly from maintainers of in-tree or out-of-tree backends that might be simplified with such a change. * Sanjoy Das is looking for feedback on his proposal to [improve Scalar Evolution's behaviour on IR with no-wrap flags](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105108.html). Sanjoy's introduction to the problem is very clearly written, so I suggest the interested reader click through and take a look. Fundamentally, Sanjoy's proposal is that poison values are modeled as data within SCEV. An alternative approaches was [suggested](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105114.html) in some of the following discussion, which would be to represent proofs about IR values independently from SCEV. * Dylan McKay is [looking for help](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105147.html) with reviews of patches under submission for the AVR backend. * Zachary Turner has made a large list of ideas for the [next step of LLDB evolution](http://lists.llvm.org/pipermail/lldb-dev/2016-September/011262.html). Proposals include removing LLDB code that duplicates similary functionality in LLVM (particularly support code like lldb::Regex), adding a suite of smaller utilities such as lldb-breakpoint lldb-symbol and more to ease testing, and improving LLDB's testing. The thread contains 64 responses at the time of writing discussing the details of this proposal. * Ayal Zaks has shared an RFC on [extending the loop vectorizer to vectorize outer-loops](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105100.html). The current loop vectorizer will only handle innermost loops, and Ayal lists a series of modifications that could be made to change this. The feedback so far appears to be positive. * Elena Demikhovsky has posted an RFC on [adding new masked.expandload and masked.compressstore intrinsics](http://lists.llvm.org/pipermail/llvm-dev/2016-September/104985.html). These would be lowered to AVX-512 VCOMPRESS and VEXPAND and scalarized on other targets. * Vendat Kumar has announced a new [LLVM code coverage bot](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105094.html) which will produce automatically updated coverage reports. As you would expect, these reports are generated using llvm-cov. * Duncan P. N. Exon Smith proposes that [ConstantData should not have use-lists](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105157.html). ConstantData was added as a parent type for constants with no operations such as `i32 0` and `null`. Duncan outlines a plan for removing use-lists for these values and has attached some initial patches to do this. ## LLVM commits * I missed it last week, but there has been a minor change to the stackmap format which will require external tools parsing stackmaps to be updated. Per-function callsite counts were added. [r281532](https://reviews.llvm.org/rL281532). * Documentation has been extended for the AMDGPU backend. [r281962](http://reviews.llvm.org/rL281962). * The check-coverage-regressions script has been deleted due to being too noisy for practical use. [r281871](http://reviews.llvm.org/rL281871). * Support for XRay on 32-bit ARM has been committed. [r281878](http://reviews.llvm.org/rL281878). * Development of GlobalISel continues with, amongst other changes, support for stack-based parameters on AArch64. [r282153](http://reviews.llvm.org/rL282153). * StringRef gained some predicated searching functions to return or remove characters until a condition is met. [r282346](http://reviews.llvm.org/rL282346). ## Clang commits * A new tool, clang-change-namespace was born. This tool supports changing the containing namespace of class/function definitions while keeping references to types in the changed namespace correctly qualified. [r281918](http://reviews.llvm.org/rL281918). * This week has in fact seen the birth of two new clang tools. clang-move will move a specific class definition from a file to a new one, handling forward declarations etc. in the process. [r282070](http://reviews.llvm.org/rL282070). * Detailed user-facing documentation has been added for ThinLTO. [r282089](http://reviews.llvm.org/rL282089). * A new checker was added that detects calls to blocking functions (such as sleep or read) in a critical section. [r282011](http://reviews.llvm.org/rL282011). * The git-clang-format script gained an option to diff between two commits (rather than just from a commit against the working tree). [r282136](http://reviews.llvm.org/rL282136). ## Other project commits * lldb learned to highlight the column within a source line where a thread is stopped. [r282105](http://reviews.llvm.org/rL282105). * LLD's support for linkerscripts continues to improve. It can now handle `>>`, `<<`, and `DEFINED()`. [r282243](http://reviews.llvm.org/rL282243), [r282245](http://reviews.llvm.org/rL282245).