[llvm-dev] LLVM Weekly - #200, Oct 30th 2017

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 30 13:09:03 PDT 2017


LLVM Weekly - #200, Oct 30th 2017
=================================

If you prefer, you can read a HTML version of this email at
<http://llvmweekly.org/issue/200>.

Welcome to the two hundredth 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](https://www.linkedin.com/in/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 <asb at asbradbury.org>, or
@llvmweekly or @asbradbury on Twitter.


## News and articles from around the web

The next Zurich Compiler and Code Generation Social will take place [on
November
9th](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118568.html) at 7pm
and feature the talk "The RISC-V effort and the PULP project at ETH Zurich".

The Arm HPC workshop will take place 12th-13th Dec in Tokyo, and the [call for
papers/participation](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118565.html)
is now open.


## On the mailing lists

* "escha" has shared a patch and RFC on [modifying reassociate for improved
common subexpression
elimination](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118476.html).
On private graphics shader benchmarks, this has helped to reduce instruction
count. The patch is now [up for review](https://reviews.llvm.org/D39340).

* Dan Gohman has kicked off a new discussion on [handling infinite loops with
no side
effects](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118558.html).
Such loops are undefined behaviour in C++, but may have defined behaviour for
other source languages.

* Sam McCall has posted an RFC on [adding a newly written JSON library to LLVM
Support](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118583.html).

* Alessandro Di Federico has shared [work on using XPath as a query language
for LLVM
IR](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118609.html).

* Chandler Carruth has started an RFC thread on [reserving function names
recognised by
TargetLibraryInfo](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118552.html).
David Chisnall
[suggests](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118559.html)
that the frontend should be responsible for adding metadata to indicate when a
given function is "special".

* Geoff Berry has shared an RFC on [adding a bit to register
MachineOperands](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118469.html).
This bit would be used to track whether a register definition was a virtual
register before register allocation.

* Rui Ueyama posted a proposal on [making `.eh_frame` more
linker-friendly](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118493.html).

* Bingfeng Mei asked about [differences in bitfield handling between
Clang/LLVM and
GCC](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118507.html).
Joseph Myers [provided some
insight](https://gcc.gnu.org/ml/gcc/2017-10/msg00192.html) on the GCC list.

* Vedant Kumar shared [notes and
updates](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118428.html)
from the code coverage birds of a feather session at the LLVM Dev Meeting.

* Andrew Trick has [provided insight into the MicroOpBufferSize
parameter](http://lists.llvm.org/pipermail/llvm-dev/2017-October/118479.html).


## LLVM commits

* Infrastructure to support padding code with nop instructions in the MC layer
has been committed. This will be used for performance improvements on Intel
targets (see the
[RFC](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107223.html)).
[r316413](http://reviews.llvm.org/rL316413).

* GlobalISel can now import store SelectionDAG rules.
[r316360](http://reviews.llvm.org/rL316360).

* Runtime preemption specifiers can now be attached to global variables,
functions and aliases. `dso_preemptable` indicates the function/variable could
be replaced by a symbol from a different linkage unit at runtime, while
`dso_local` means this is not possible.
[r316668](https://reviews.llvm.org/rL316668).

* The X86 backend gained a "domain reassignment" pass. This will look for
cases where it is profitable to e.g. convert from the GPR domain to the Mask
domain (vector mask registers). [r316288](https://reviews.llvm.org/rL316288).

* The greedy register allocator was improved to avoid bad eviction chains (see
the commit message for an example).
[r316295](http://reviews.llvm.org/rL316295).

* Brief documentation has been added on SelectionDAG rule imports for
GlobalISel. [r316350](http://reviews.llvm.org/rL316350).

* Instruction scheduling information as been added for the Intel Broadwell
microarchitecture. [r316492](http://reviews.llvm.org/rL316492).

* The CalledValuePropagation pass has been introduced, which will attach
!callees metadata to indirect call sites.
[r316576](https://reviews.llvm.org/rL316576).


## Clang commits

* The basics of clang-refactor "extract function" functionality has been
implemented. [r316465](https://reviews.llvm.org/rL316465).

* A new `clang::tooling:ToolExecutor` interface was introduced, which is
expected to replace the `ClangTool` interface for executing frontend actions
on a set of translation units. [r316653](https://reviews.llvm.org/rL316653).


## Other project commits

* LLD can now emit relocations in Android's relocation packing format. As
described in the commit message, the algorithm used here is more advanced than
the one in the gold linker, producing even smaller relocation sections.
[r316775](https://reviews.llvm.org/rL316775).

* LLD gained support for range extension thunks on ARM. See Peter Smith's
[previous mailing list
message](http://lists.llvm.org/pipermail/llvm-dev/2017-January/108676.html)
for an introduction to range extension thunks.
[r316752](https://reviews.llvm.org/rL316752),
[r316754](https://reviews.llvm.org/rL316754).


## Review corner

The LLVM Weekly review corner serves to highlight patches that are stuck
waiting awaiting review, or work from first-time contributors. See
[here](http://llvmweekly.org/reviewcorner) for more information and how to
submit you work for inclusion. Of course the hope is that highlighting these
patches will enable LLVM Weekly readers will step up and help to get them
merged. I'll be reporting back each week on any activity generated on these
patches, as well as sharing a new batch. If you want your patch included you
must submit it via the linked form.

There were two patch submissions last week, both of which saw fresh review
activity. Thank you to Quentin Colombet and Simon Pilgrim for contributing
review comments.

I haven't received any submissions to the review corner this week.


More information about the llvm-dev mailing list