[llvm-dev] LLVM Weekly - #144, Oct 3rd 2016

[Alex Bradbury via llvm-dev]

LLVM Weekly - #144, Oct 3rd 2016
================================

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

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

The short paper '[Compiling with Continuations and
LLVM](http://kavon.farvard.in/papers/ml16-cwc-llvm.pdf)' from the recent ML
workshop may be interesting to LLVM Weekly Readers. See also the
[slides](http://kavon.farvard.in/papers/ml16-slides.pdf).

I linked to the [CppCon 2016
videos](https://www.youtube.com/playlist?list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH)
last week, but since then many more have been uploaded so I feel it's worth
featuring again. There's discussion about many of the talks on the [cpp
subreddit](https://www.reddit.com/r/cpp/).

The Zurich LLVM Social will be [taking
place](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105187.html) on
Thursday Oct 13th.


## On the mailing lists

* Mehdi Amini has started a thread to discuss [the stability policy of the
libLTO C
API](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105461.html). At
this stage he is trying to identify the key stakeholders. A number of users of
this API have chimed in to say they're interested in discussing this.

* Artur Pilipenko kicked off a [discussion about the load combine
pass](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105291.html).
Both [David
Chisnall](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105434.html)
and [Simon
Dardis](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105436.html)
explained cases where load combining can actually reduce performance.

* Chris Bieneman suggests that [for every test marked as XFAIL, a bug should
be
filed](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105296.html).
This could be enforced using lit. A concern was raised that some backends have
XFAILs that [aren't
bugs](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105300.html).
Arguably these [could be written to use REQUIRE
instead](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105301.html).

* Abe Skolnik has
[proposed](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105383.html)
a script to help make tests tolerant of floating point errors that may be
introduced by new optimisations, e.g. use of fused multiply-add. After
feedback from Hal Finkel and others, he [adjusted his
approach](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105410.html).

* Sanjoy Patel kicked off a [discussion about canonical lowering of
selects](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105335.html).
Although Chris Lattner
[commented](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105345.html)
that in the general case, canonicalizing towards simpler single-IR instruction
forms is preferred, Sanjoy Das had some [good
examples](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105346.html)
of why you might prefer canonicalizing to selects.

* Mehdi Amini [shared some
results](http://lists.llvm.org/pipermail/llvm-dev/2016-September/105273.html)
from an experiment in replacing the LLVM bitcode format with something using
Google's Flatbuffers. The main motivation was to provide random access. In the
current prototype, outputted files are about 2x larger than standard LLVM
bitcode.

* Daniel Austin Noland has written an [RFC on refactoring LLDB
break/watchpoints](http://lists.llvm.org/pipermail/lldb-dev/2016-September/011394.html).
He lists a number of extra features he would like to offer after the refactor.

* Zachary Turner [kicked
off](http://lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html) a
discussion about bumping the pre-requisites for building LLVM to a baseline
that offers partial C++14 support. A number of people have responded saying
that moving away from GCC 4.8 to 4.9 or above might be a problem for them.


## LLVM commits

* The upstreaming with AVR support for LLVM continues with the addition of an
assembly parser. [r282584](http://reviews.llvm.org/rL282584).

* The `WritingAnLLVMPass` document has received a large update to better
reflect current LLVM. [r282482](http://reviews.llvm.org/rL282482).

* lit gained a new `--max-failures` option. If set, it will stop running tests
after the given number of failures.
[r282452](http://reviews.llvm.org/rL282452).

* To allow for better tool integration, optimisation remarks can now be output
in YAML. [r282499](http://reviews.llvm.org/rL282499).

* Symbolized coverage files have been introduced, these include all necessary
symbol information to answer common queries.
Alongside that, a python script providing a HTTP server to browse coverage
reports from these .symcov files. The motivation is that in most cases,
generating huge coverage reports statically isn't required or desirable.
[r282639](http://reviews.llvm.org/rL282639),
[r282637](http://reviews.llvm.org/rL282637).


## Clang commits

* A new `-save-stats` option has been added which will write out internal LLVM
code generation statistics in JSON format to a file.
[r282426](http://reviews.llvm.org/rL282426).

* The proposed C++17 evaluation order tweaks have now all been implemented,
though some are unimplementable on Windows without breaking the ABI (which
requires function arguments are evaluated from right to left).
[r282619](http://reviews.llvm.org/rL282619).

* The documentation for the clang-include-fixer now includes details of
available settings for the Vim and Emacs plugins.
[r282480](http://reviews.llvm.org/rL282480).


## Other project commits

* `std::move` and `std::forward` are now marked constexpr in libcxx.
[r282439](http://reviews.llvm.org/rL282439).

* lld now uses xxhash to produce a buildid, resulting in speedups for a few
percent. [r282505](http://reviews.llvm.org/rL282505).