Alex Bradbury via llvm-dev
2016-Oct-03 12:24 UTC
[llvm-dev] LLVM Weekly - #144, Oct 3rd 2016
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).