[llvm-dev] LLVM Weekly - #126, May 30th 2016

[Alex Bradbury via llvm-dev]

LLVM Weekly - #126, May 30th 2016
=================================

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

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

I've been moving house this weekend, so do accept my apologies if you find
this issue to be a little less thorough than usual.


## News and articles from around the web

Pyston, the LLVM-based Python compiler has [released version
0.5](https://blog.pyston.org/2016/05/25/pyston-0-5-released/). The main
changes are a switch to reference counting and NumPy compatibility.

I don't want to become "C++ weekly", but I think this audience appreciates a
fun use of C++ features.
[Verdigris](https://woboq.com/blog/verdigris-qt-without-moc.html) is a
header-only library that allows you to use Qt5 without the moc preprocessor.

The call for papers for the [3rd workshop on the LLVM compiler infrastructure
in HPC](http://lists.llvm.org/pipermail/llvm-dev/2016-May/100107.html) has
been published. The deadline for paper submission is September 1st. The
workshop will take place on November 14th in Salt Lake City, and is held in
conjunction with SC16.


## On the mailing lists

* Vivek Pandya, a GSoC student working on interprocedural register allocation
has shared [a weekly status
report](http://lists.llvm.org/pipermail/llvm-dev/2016-May/100227.html).

* Rafael Espíndola has proposed [creating a bitcode symbol
table](http://lists.llvm.org/pipermail/llvm-dev/2016-May/100190.html).

* There's been
[some](http://lists.llvm.org/pipermail/llvm-dev/2016-May/100169.html)
[updates](http://lists.llvm.org/pipermail/llvm-dev/2016-May/100170.html) on
the progress of open-sourcing PGI's Fortran frontend.

* Elena Lepilkina has proposed some [enhancement to
FileCheck](http://lists.llvm.org/pipermail/llvm-dev/2016-May/100024.html).
Some questions were raised about how useful the proposed extensions will be.
Sergey Yakoushkin provided more background on [how these features are
used](http://lists.llvm.org/pipermail/llvm-dev/2016-May/100162.html) in a
commercial codebase. As Elena notes, these features don't need to all be
upstreamed at once (or at all), and are mostly independent.

* Lang Hames has posted a heads-up about [upcoming breaking API changes for
ORC and MCJIT](http://lists.llvm.org/pipermail/llvm-dev/2016-May/100061.html).

* Sean Silva has kicked off a discussion on [the state of
IRPGO](http://lists.llvm.org/pipermail/llvm-dev/2016-May/100021.html). You
might ask what is IRPGO? This is profile-guided optimisation performed through
instrumentation at the LLVM IR level, as opposed to FEPGO where
instrumentation is added by the frontend (e.g. Clang), prior to lowering to
IR. Sean would like to make IRPGO the default on all platforms other than
Apple at the moment (who may require a longer deprecation period). A number of
followup comments discuss possibilities for ensuring all platforms can move
forward together, and ensuring a sensible flag exists to choose between
frontend or middle-end PGO.

* What exactly is a register pressure set? Both [Quentin
Colombet](http://lists.llvm.org/pipermail/llvm-dev/2016-May/100004.html) and
[Andrew Trick](http://lists.llvm.org/pipermail/llvm-dev/2016-May/100019.html)
have answers for us.


## LLVM commits

* New optimisations covering checked arithmetic were added.
[r271152](http://reviews.llvm.org/rL271152),
[r271153](http://reviews.llvm.org/rL271153).

* Advanced unrolling analysis is now enabled by default.
[r270478](http://reviews.llvm.org/rL270478).

* The initial version of a new chapter to the 'Kaleidoscope' tutorial has been
committed. This describes how to build a JIT using ORC.
[r270487](http://reviews.llvm.org/rL270487),
[r271054](http://reviews.llvm.org/rL271054).

* LLVM's stack colouring analysis data flow analysis has been rewritten in
order to increase the number of stack variables that can be overlapped.
[r270559](http://reviews.llvm.org/rL270559).

* Parts of EfficiencySanitizer are starting to land, notably instrumentation
for its working set tool. [r270640](http://reviews.llvm.org/rL270640).

* SelectionDAG learned how to expand multiplication for larger integer types
where there isn't a standard runtime call to handle it.
[r270720](http://reviews.llvm.org/rL270720).

* LLVM will now report more accurate loop locations in optimisation remarks by
reading the starting location from llvm.loop metadata.
[r270771](http://reviews.llvm.org/rL270771).

* Symbolic expressions are now supported in assembly directives, matching the
behaviour of the GNU assembler. [r271102](http://reviews.llvm.org/r271102).

* Symbols used by plugins can now be auto-exported on Windows, which improves
support for plugins in Windows. See the commit message for a full description.
[r270839](http://reviews.llvm.org/rL270839).


## Clang commits

* Software floating point for Sparc has been exposed in Clang through
`-msoft-float`. [r270538](http://reviews.llvm.org/rL270538).

* Clang now supports the `-finline-functions` argument to enable inlining
separately from the standard `-O` flags.
[r270609](http://reviews.llvm.org/rL270609).


## Other project commits

* SectionPiece in LLD is now 8-bytes smaller on 64-bit platforms. This
improves the time to link Clang with debug info by 2%.
[r270717](http://reviews.llvm.org/rL270717).

* LLD has replaced a use of binary search with a hash table lookup, resulting
in a 4% speedup when linking Clang with debug info.
[r270999](http://reviews.llvm.org/rL270999).

* LLDB now supports AArch64 compact unwind tables, as used on iOS, tvos and
watchos. [r270658](http://reviews.llvm.org/rL270658).