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

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 26 04:54:50 PDT 2016

LLVM Weekly - #143, Sep 26th 2016

If you prefer, you can read a HTML version of this email at

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

Sanjoy Das has written up a blog post about [how integer overflow fits in with

The APOLLO runtime-speculative polyhedral loop optimiser and parallelizer has
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
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

## On the mailing lists

* Serge Pavlov [proposes that Clang support configuration
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
and Richard Pennington dropped by to explain [the solution he uses for

* Krzysztof Parzyszek has shared an RFC on supporting [variable-sized register
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
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
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
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
in some of the following discussion, which would be to represent proofs about
IR values independently from SCEV.

* Dylan McKay is [looking for
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
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
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
These would be lowered to AVX-512 VCOMPRESS and VEXPAND and scalarized on
other targets.

* Vendat Kumar has announced a new [LLVM code coverage
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
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.

* Documentation has been extended for the AMDGPU backend.

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

* Development of GlobalISel continues with, amongst other changes, support for
stack-based parameters on AArch64.

* StringRef gained some predicated searching functions to return or remove
characters until a condition is met.

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

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

* A new checker was added that detects calls to blocking functions (such as
sleep or read) in a critical section.

* The git-clang-format script gained an option to diff between two commits
(rather than just from a commit against the working tree).

## 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),

More information about the llvm-dev mailing list