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

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Mon May 23 03:55:28 PDT 2016

LLVM Weekly - #125, May 23rd 2016

If you prefer, you can read a HTML version of this email at

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
He also makes use of

Krister Walfridsson has written a wonderfully clear post on [C's type-based

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

## 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
worthwhile? Hideki Saito posted a useful [summary of the discussion so

* 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
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

* Quentin Colombet has [summarised recent discussion on policies to help
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
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

## 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.

* `Reloc::Default` no longer exists. Instead, `Optional<Reloc>` is used.

* An initial implementation of a "guard widening" pass has been committed.
This will combine multiple guards to reduce the number of checks at runtime.

## Clang commits

* clang-include-fixer gained a basic Vim integration.

* 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.

## Other project commits

* lld now lets you specify a subset of passes to run in LTO.

* LLDB has replaced uses of its own Mutex class with `std::mutex`.

More information about the llvm-dev mailing list