[llvm-dev] LLVM Weekly - #125, May 23rd 2016

[Alex Bradbury via llvm-dev]

LLVM Weekly - #125, May 23rd 2016
=================================

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

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

Steve Ire has written a blog post about [using Clang through the cindex API to
automatically generate Python
bindings](https://steveire.wordpress.com/2016/05/18/generating-python-bindings-with-clang/).
He also makes use of
[SIP](https://www.riverbankcomputing.com/software/sip/intro).

Krister Walfridsson has written a wonderfully clear post on [C's type-based
aliasing
rules](http://kristerw.blogspot.co.uk/2016/05/type-based-aliasing-in-c.html).

This week I discovered the [Swift Weekly Brief
newsletter](http://swiftweekly.github.io/). Its author, Jesse Squires does a
wonderful job of summarising mailing list traffic, recent commits, and
discussions on swift-evolution proposals. If you have an interest in Swift
development or language design in general I highly recommend it.

Are you interested in [writing for the LLVM
blog](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099807.html)? Or
volunteering to help recruit content authors? If so, get in touch with Tanya.

The next Cambridge LLVM Social will be held [at 7.30pm on May 25th at the
Cambridge
Blue](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099870.html).


## On the mailing lists

* Elena Demikhovsky is interested in [extending scalar evolution (SCEV)
analysis to include floating point
support](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099724.html). This
kicked off a pretty interesting discussion. Sanjoy Das highlighted what he
sees as the [most important issues to
discuss](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099743.html). A
number of follow-ups discussed whether enough code uses floating point values
as an induction variable to be worth optimising. There was also the question
of [should vectorisation be pursued at any
cost?](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099819.html). Even if
a loop can be made vectorisable through loop-versioning with run-time checks,
is it worth the code size? Is the [cost of maintaining the compiler
code](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099814.html)
worthwhile? Hideki Saito posted a useful [summary of the discussion so
far](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099928.html).

* Chandler Carruth is looking for feedback on the idea of [supporting
horizontal operations on vector types such as sum directly in LLVM
IR](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099715.html). Everyone
who has responsed so far is in favour.

* Jia Chen, GSoC student with LLVM, has noted the CFL-AA pass seems to be
mostly working now and would [appreciate reports from people trying it out on
their
codebases](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099742.html).So
far, Geoff Berry
[reports](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099900.html) no
correctness issues but seemingly very limited changes in the generated code
for SPEC and the LLVM test-suite.

* Adam Nemet is seeking feedback on the idea of [adding optimisation remarks
to indicate where non-temporal stores may be
profitable](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099873.html).

* Quentin Colombet has [summarised recent discussion on policies to help
release
management](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099752.html) and
detailed the automatic hooks he hopes to explore next for updating bugs when
referenced in a commit message. The following discussion looked at how these
hooks may be implemented and what level of rigidity would be most beneficial
to the community.

* Dean Michael Berris is looking for a way of [defining a default
implementation for a
pseudo-instruction](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099759.html).
No answers yet, but hopefully that will change soon!

* Galena Kistanova is doing some cleanup work on zorg (the buildbot-based
testing infrastructure of the LLVM project) and is interested whether [anyone
uses these seemingly stale
modules](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099739.html).


## LLVM commits

* llc will now report all errors in the input file rather than just exiting
after the first. [r269655](http://reviews.llvm.org/rL269655).

* The SPARC backend gained support for soft floating point.
[r269892](http://reviews.llvm.org/rL269892).

* `Reloc::Default` no longer exists. Instead, `Optional<Reloc>` is used.
[r269988](http://reviews.llvm.org/rL269988).

* An initial implementation of a "guard widening" pass has been committed.
This will combine multiple guards to reduce the number of checks at runtime.
[r269997](http://reviews.llvm.org/rL269997).


## Clang commits

* clang-include-fixer gained a basic Vim integration.
[r269927](http://reviews.llvm.org/rL269927).

* The intrinsics headers now have feature guards enabled in Microsoft mode to
combat the compile-time regression discussed last week due to their increased
size. [r269675](http://reviews.llvm.org/rL269675).

* avxintrin.h gained many new Doxygen comments.
[r269718](http://reviews.llvm.org/rL269718).


## Other project commits

* lld now lets you specify a subset of passes to run in LTO.
[r269605](http://reviews.llvm.org/rL269605).

* LLDB has replaced uses of its own Mutex class with `std::mutex`.
[r269877](http://reviews.llvm.org/rL269877),
[r270024](http://reviews.llvm.org/rL270024).