[llvm-dev] LLVM Weekly - #118, Apr 4th 2016

[Alex Bradbury via llvm-dev]

LLVM Weekly - #118, Apr 4th 2016
================================

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

Welcome to the one hundred and eighteenth 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

Almost all slides from the recent EuroLLVM conference are [now available
online](http://llvm.org/devmtg/2016-03/) for your enjoyment.

Some readers my be interested in a new paper about the 'LifeJacket' tool for
[verifying precise floating-point optimisations in
LLVM](http://arxiv.org/abs/1603.09290).

Christian Neumüller has written a [new tool for syntax highlighting and
cross-referencing C and C++ source](https://github.com/oberon00/synth) using
libclang.


## On the mailing lists

* Chandler Carruth suggests that just like commits that break codegen are
immediately reverted, [commits that introduce large, especially super-linear
compile time regressions should be
reverted](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097849.html).
There's a lot of agreement in the general principle in replies, though some
point out that much of the slowdown across the past few LLVM and Clang
versions is due to a large number of small changes.

* James Molloy is interested in discussing [how LLVM could learn the size of a
particular
std::vector](http://lists.llvm.org/pipermail/llvm-dev/2016-April/097877.html)
and omit unnecessary checks etc.

* Nick Johnson has a [couple of questions about IfConversion in
LLVM](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097755.html). They
haven't been answered yet, but I know I'd be interested in the answer.

* Russell Wallace has kicked off a very useful thread about [generating calls
to existing functions from the
JIT](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097675.html).

* Zachary Turner is interested in [people's feelings on requiring a minimum of
MSVC 2015 to compile LLVM and
Clang](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097756.html). The
general feeling so far is that it's too early for this, as typically the
policy is to support the last two major MSVC releases.

* Hans Wennborg has kindly highlighted a [recent API change to
TargetFrameLowering::eliminateCallFramePseudoInstr](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097844.html)
that will be of interest to maintainers of out-of-tree backends.

* Matt Masten has posted an RFC on [vectorizing loops with calls to math
functions using
SVML](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097862.html)
(Intel's short vector math library).

* Eric Christopher has posted an RFC on [migrating debug type information
generation from the backends to the
frontend](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097773.html).

* Ke Bai's [memory scope
proposal](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097355.html)
hasn't really seen any responses up to now. Philip Reames does [share some
feedback](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097726.html),
but notes it's unlikely this proposal could realistically be merged in to LLVM
unless there is more interest. If this is an area that interests you, then
please do have a good read of Ke's proposal.


## LLVM commits

* The Lanai backend has landed. [r264578](http://reviews.llvm.org/rL264578).

* A new `llvm.experimental.guard` intrinsic has been added. As described in
the accompanying documentation, along with deoptimization operand bundles this
allows frontends to express guards or checks on optimistic assumptions made
during compilation. [r264976](http://reviews.llvm.org/rL264976).

* Support for a number of new Altivec instructions has been added. Amazingly,
this includes BCD (Binary Coded Decimal) instructions.
[r264568](http://reviews.llvm.org/rL264568).

* The concept of MachineFunctionProperties has been introduced, with the first
property being AllVRegsAllocated. This allows passes to declare that they
require a particular property, in this case requiring that they be run after
regalloc. [r264593](http://reviews.llvm.org/rL264593).

* On X86, push will now be used in preference to mov at all optimisation
levels (before it was only enabled for `-Os`).
[r264966](http://reviews.llvm.org/rL264966).

* LLVM's support library can now compute SHA1 hashes. This is used to
implement a 'build-id'. [r265094](http://reviews.llvm.org/rL265094),
[r265095](http://reviews.llvm.org/rL265095).

* When metadata is only referenced in a single function, it will now be
emitted just in that function block. The aim of this is to improve the
potential of lazy-loading. [r265226](http://reviews.llvm.org/rL265226).


## Clang commits

* The Lanai backend is now supported in the Clang driver.
[r264655](http://reviews.llvm.org/rL264655).

* libTooling gained a handy formatAndApplyAllReplacements function.
[r264745](http://reviews.llvm.org/rL264745).


## Other project commits

* Parts of LLD are starting to use the new Error handling.
[r264910](http://reviews.llvm.org/rL264910),
[r264921](http://reviews.llvm.org/rL264921),
[r264924](http://reviews.llvm.org/rL264924), and more.

* Infrastructure was added to LLD for generating thunks (as required on
platforms like MIPS when calling PIC code from non-PIC).
[r265059](http://reviews.llvm.org/rL265059).