[llvm-dev] LLVM Weekly - #95, Oct 26th 2015

[Alex Bradbury via llvm-dev]

LLVM Weekly - #95, Oct 26th 2015
================================

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

Welcome to the ninety-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

The C++ Standardization Committee just finished up their most recent meeting,
and STL (Stephan T. Lavavej) has [provided a useful
summary](https://www.reddit.com/r/cpp/comments/3q4agc/c17_progress_update_oct_2015/).
Herb Sutter has also [posted a trip
report](http://herbsutter.com/2015/10/25/2568/).

The HHVM team have posted an [update on the status of LLVM code generation in
HHVM](http://hhvm.com/blog/10205/llvm-code-generation-in-hhvm). They managed
to get LLVM to equal the performance of their custom backend, but are not
going to deploy the LLVM backend to production for now. They're no longer
actively working on the LLVM backend, but hope to ensure it doesn't regress.

Hal Finkel is [proposing an LLVM social in Austin on the evening of November
15th](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091612.html).
There should be a high density of LLVM users due to the [LLVM in HPC
workshop](http://llvm-hpc2-workshop.github.io/).


## On the mailing lists

* The biggest discussion this week in the LLVM community is the [proposed
change to the Apache
license](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html).
One motivation is that some companies feel blocked from contributing due to
the wording in the patent section of the LLVM developer policy, though see the
linked message for a full summary. Concerns were raised about the fact that
Apache 2 is incompatible with the GPLv2 and that [license complexity may put
off contributors, such as the FreeBSD
community](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091642.html).

* Robert Cox has posted an [RFC on adding the ability for LLVM to produce an
inlining
report](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091687.html).
This report would give details on where inlining has taken place and why.
Initial feedback is positive.

* More information for birds of a feather sessions at the upcoming LLVM dev
meeting has gone out. Kristof Beyls is running one on [performance tracking
and benchmarking
infrastructure](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091736.html),
John Criswell on [sophisticated program analysis on LLVM
IR](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091552.html), and
Paul Robinson on [living downstream without
drowning](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091546.html).

* Gaël Jobin has a [fantastic
answer](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091685.html) to
a question about handling intrinsics in your backend.

* Louis Brandy is a Facebook employee who is [starting to work on enabling
Clang module support for their C++
codebase](http://lists.llvm.org/pipermail/cfe-dev/2015-October/045706.html).
He's interested in experiences from anyone on incrementally adding module maps
to a large codebase.

* A lot of work has been done to extend Clang's static analyzer to support
interprocedural analysis. This thread [discusses the current state and path
forward](http://lists.llvm.org/pipermail/cfe-dev/2015-October/045665.html).
It's not giving the improvement expected (in terms of detected
bugs-per-second) and the thread discusses thoughts on why.


## LLVM commits

* The `TargetLowerBase::LibCall` LegalizeAction has been introduced. This
allows backends to control whether they prefer expansion or conversion to a
libcall. [r250826](http://reviews.llvm.org/rL250826).

* The Hexagon backend continues to accumulate sophisticated target-specific
optimisations. HexagonBitSimplify continues a number of transformations to
perform simplifications, redundant code elimination etc.
[r250868](http://reviews.llvm.org/rL250868).

* The new AliasAnalysis infrastructure gained an optional 'external' AA
wrapper pass, to allow users to merge in external AA results. The unit test
included in the patch gives a good example of how to use this.
[r250894](http://reviews.llvm.org/rL250894).

* CodeGenPrepare can now transform select instructions into branches and sink
expensive operands. [r250743](http://reviews.llvm.org/rL250743).

* Loop rotation can now use profile data in making decisions during
MachineBlockPlacement. [r250754](http://reviews.llvm.org/rL250754).

* ValueTracking now has a `isKnownNonEqual` predicate.
[r251012](http://reviews.llvm.org/rL251012).


## Clang commits

* Basic (currently parsing and basic semantic analysis) support for the
anticipated C++1z coroutine feature was added.
[r250980](http://reviews.llvm.org/rL250980),
[r250985](http://reviews.llvm.org/rL250985),
[r250993](http://reviews.llvm.org/rL250993).

* `-fvisibility=internal` is now aliased to `-fvisibility=hidden`, as LLVM
doesn't currently support internal visibility.
[r250954](http://reviews.llvm.org/rL250954).

* Clang's static analyzer learnt to associate hashes with found issues. This
hash aims to be resilient to code changes, so should be useful for suppressing
false positives. [r251011](http://reviews.llvm.org/rL251011).


## Other project commits

* lld gained support for lazy relocations on x86-64.
[r250808](http://reviews.llvm.org/rL250808).

* The new LLD ELF linker now supports the `--gc-sections` parameter. This
increases the time to link Clang by 8% bus reduces the size of the output
binary by 4%. [r251043](http://reviews.llvm.org/rL251043).

* LLDB gained a REPL. [r250753](http://reviews.llvm.org/rL250753),
[r250773](http://reviews.llvm.org/rL250773).

* DWARF parsing in LLDB can now be multi-threaded, which can drastically
incrase the speed of loading debug info.
[r251106](http://reviews.llvm.org/rL251106).