[llvm-dev] LLVM Weekly - #143, Sep 26th 2016

[Alex Bradbury via llvm-dev]

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).