[llvm-dev] LLVM Weekly - #138, Aug 22nd 2016

Mon Aug 22 04:28:51 PDT 2016

LLVM Weekly - #138, Aug 22nd 2016
=================================

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

Welcome to the one hundred and thirty-eighth 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

LLVM and Clang [3.9.0-rc2 has been
tagged](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103857.html).

A seemingly anonymous blog post has been written introducing [new LLVM passes
to increase code coverage with AFL and similar
fuzzers](https://lafintel.wordpress.com/2016/08/15/circumventing-fuzzing-roadblocks-with-compiler-transformations/).
These passes de-optimize code generated by LLVM.

The 2016 US LLVM Developers' Meeting's [call for
papers](http://llvm.org/devmtg/2016-11/#cfp) closes this Thursday, 25th
August. The LLVM Foundation have also announced a [student travel grant
program](http://llvm.org/devmtg/2016-11/#grant).

We've announced the main track talks [schedule for the LLVM Cauldron
2016](http://llvm.org/devmtg/2016-09/#schedule). This one-day conference will
take place on September 8th in Hebden Bridge, UK. If you're still weighing up
whether to make the trip, you may also want to review the line-up for the [GNU
Tools Cauldron](https://gcc.gnu.org/wiki/cauldron2016) which takes place over
the following two days. Registration is free, so go ahead and [register
now](http://llvm.org/devmtg/2016-09/#register).

The next [Cambridge LLVM
Social](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103934.html) will
take place on Tuesday 6th September. It's timed so hopefully people will be
able to attend before travelling to Hebden Bridge for the LLVM and GNU
Cauldrons.

## On the mailing lists

* Alex Bradbury (disclosure: that's me) posted an RFC for [inclusion of a new
RISC-V backend in
LLVM](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html). A
series of patches has been submitted that introduces the MC layer, and the
plan is to continue submitting changes incrementally in reviewable chunks.
"Producing a series of patches that introduce RISC-V
support incrementally in easy-to-review chunks with associated test cases at
every point also allows us to get the maximum benefit from LLVM's code review
procedure." Responses have been positive so far.

* Ed Jones has posted an RFC on [adding the AAP backend to
LLVM](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103807.html).
[AAP](http://www.embecosm.com/resources/appnotes/#EAN13) is designed as a
reference architecture representative of many deeply embedded Harvard
architectures used in in industry. The thread hasn't generated much feedback
yet.

* Renato Golin is seeking feedback through an [RFC on the formation of a
survey on the proposed GitHub
move](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103862.html). This
thread is attempting to hone in on a set of questions that will be most
effective at getting feedback from the wider community of LLVM developers and
downstream users.

* Zachary Turner has [proposed a cross-platform replacement for the use of
Unix utilities used in lit
tests](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103713.html). He
firstly notes that many lit tests that claim to require a Unix shell actually
don't, given that GNUWin32 is already a dependency. Removing that GNUWin32
dependency is [also
discussed](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103732.html)
of course.

* Eric Fiselier suggests that [LLVM release candidate binaries should not
disable
assertions](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103680.html).
Many respondents can see the argument for this, but also point out that the
build configuration then wouldn't match the configuration used for the release
binary.

## LLVM commits

* The official policy for accepting a new LLVM backend target have now been
added to the developer policy. [r278971](http://reviews.llvm.org/rL278971).

* Initial documentation has been added for MemorySSA.
[r278875](http://reviews.llvm.org/rL278875).

* Work is being done on the aggressive dead code elimination pass to
eventually support removing unnecessary control flow.
[r278807](http://reviews.llvm.org/rL278807).

* libFuzzer gained support for value profiling.
[r278839](http://reviews.llvm.org/rL278839).

* A flag has been added to disable manual alloca merging. As described in the
commit message, the intent is to make use of LLVM's lifetime marker based
stack coloring instead. [r278892](http://reviews.llvm.org/rL278892).

* The WebAssemblyLowerEmscriptenException pass was rewritten to support
setjmp/longjmp as well as exception handling.
[r279075](http://reviews.llvm.org/rL279075).

## Clang commits

* The concept of deferred diagnostics has been introduced. These are emitted
if and only if a particular FunctionDecl is codegenned. The motivation use
case is for CUDA. [r278735](http://reviews.llvm.org/rL278735).

* A new checker has been added to look for loss of sign or precision in
integral casts. [r278941](http://reviews.llvm.org/rL278941).

* The recently added CloneDetector gained the ability to find clones that look
like copy+paste errors. It looks for cases where exactly one variable is out
of place compared to the original code, which likely indicates the developer
forgot to rename one variable. [r279056](http://reviews.llvm.org/rL27905).

## Other project commits

* A mammoth LLDB patch has introduced a StructuredData plugin type and an
example user of this feature, DarwinLog.
[r279202](http://reviews.llvm.org/rL279202).

* The libcxx buildsystem has been updated so it can be built from the LLVM
runtimes subdirectory. [r279151](http://reviews.llvm.org/rL279151).