[llvm-dev] LLVM Weekly - #210, Jan 8th 2018

Alex Bradbury via llvm-dev
Mon, 08 Jan 2018 21:14:00 -0000

LLVM Weekly - #210, Jan 8th 2018
===============================
If you prefer, you can read a HTML version of this email at
<http://llvmweekly.org/issue/210>.

Welcome to the two hundred and tenth 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](https://www.linkedin.com/in/alex-bradbury/). 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 [call for
papers](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120148.html) for
the 2018 European LLVM Developers' Meeting has been issued. The Meeting will
be held on April 16-17 in Bristol, UK. The submission deadline is February
9th.

The release branch for 6.0.0 has been created and [trunk is now
7.0.0](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120090.html). The
first release candidate isn't scheduled until Jan 17th.

[QDBI](https://qbdi.quarkslab.com/) is a new open-source LLVM-based Dyanmic
Binary Instrumentation Tools from QuarksLab. You can find out more from this
[recent 34C3
talk](https://media.ccc.de/v/34c3-9006-implementing_an_llvm_based_dynamic_binary_instrumentation_framework).

Dan Liew has open sourced [JFS](https://github.com/delcypher/jfs) (JIT Fuzzing
Solver), a constraint solver built on top of Z3 and LibFuzzer. It works by
generating a C++ program where the reachability of an abort() statement is
equivalent to finding a satisfying assignment to the constraints, then uses
libFuzzer to solve it.

The next Zurich LLVM Social will [take
place](https://www.meetup.com/llvm-compiler-and-code-generation-socials-zurich/events/245320826/)
this Thursday 11th at 7pm. It will feature talks on timing side-channels in
modern CPUs and PySpark at bare-metal speed.

Kamil Rytarowski has posted an
[update on NetBSD Memory Sanitizer
progress](https://blog.netbsd.org/tnf/entry/the_llvm_memory_sanitizer_support).


## On the mailing lists

* The [Meltdown and Spectre attacks](https://meltdownattack.com/) have of
course been big news in the last week. LLVM patches to mitigate Spectre have
started to be posted for discussion:
[retpoline](http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513630.html),
[`__builtin_load_no_speculate`](http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/214327.html),
and the [llvm.nospeculateload
intrinsic](http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513875.html).
Chandler Carruth
[indicates](http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513879.html)
that Google expect to follow-up with some alternative API ideas to
llvm.nospeculateload.

* James Y Knight
[suggests](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120087.html)
changing the versioning scheme for the current 'trunk' version. He
observes
that incrementing the major version immediately upon branching means it's
difficult to write reliable checks such as `#if __clang_major__ >= 7`.

* Hideki Saito is
[looking](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120164.html)
for feedback on moving the `isLegalMasked*` checks to
LoopVectorizationCostModel.

* Nemanja Ivanovic is [seeking
feedback](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120171.html)
on legalizing the input operand to `ATOMIC_CMP_SWAP*` by zero-extending.

* Alex Bradbury has outlined the current in-tree uses of custom CCState and is
[looking for
feedback](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120098.html)
on ideas to remove the need for these, on requirements from out-of-tree
backends, and on supporting the same functionality in GlobalISel.

* Sander De Smalen has shared an
[RFC](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120129.html) on
extending the DISubrange count field, which can be used to improve debug
information for variable length arrays or SVE vectors.

* Daniel Neilson has
[resurrected](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120080.html)
a set of patches from 2015 to modify memcpy/memmove/memset to have destination
and source alignment attributes.


## LLVM commits

* GlobalISel is now enabled at -O0 by default for AArch64.
[r321655](http://reviews.llvm.org/rL321655).

* A new documentation page describing how to contribute to LLVM has been
added, detailing how to find topics to work on, how to submit a patch, and
where to learn more about LLVM's architecture and internals.
[r321804](http://reviews.llvm.org/rL321804).

* LLVM's OptTable class (in libLLVMOption) gained a `findNearest` method
which
can be used to implement "did you mean..." responses in LLVM tools for
unrecognised options. This functionality was previously only available in the
CommandLine library which isn't used by tools like Clang or Swift.
[r321877](http://reviews.llvm.org/rL321877).

* An MCSubtargetInfo reference is now pased through
target::createMCAsmBackend. This allows subtarget feature support to be easily
queried, with a number of follow-on cleanups suggested in the commit message.
The suggested ARMAsmBackend cleanup has already been implemented and
committed.[r321692](http://reviews.llvm.org/rL321692),
[r321707](http://reviews.llvm.org/rL321707).

* A multi-threaded implementation of llvm-cov's prepareFileReports method
results in huge speed improvements for large inputs.
[r321871](http://reviews.llvm.org/rL321871).

## Clang commits

* Clang will use a recent addition to the libLLVMOption API to suggest
correctly spelled driver options when an unrecognised argument is given.
[r321917](http://reviews.llvm.org/rL321917).

* The `-Wtautological-constant-compare` warning has intentionally limited and
is now disabled by default. As described in the commit message, there are a
number of cases where the warning may not be correctly given but unhelpful in
identifying buggy code. [r321691](http://reviews.llvm.org/rL321691).


## Other project commits

Nothing notable this week (that I spotted at least - tips on patches to
include always welcome).


## Review corner

The LLVM Weekly review corner serves to highlight patches that are stuck
waiting awaiting review, or work from first-time contributors. See
[here](http://llvmweekly.org/reviewcorner) for more information and how to
submit you work for inclusion. Of course the hope is that highlighting these
patches will enable LLVM Weekly readers will step up and help to get them
merged. I'll be reporting back each week on any activity generated on these
patches, as well as sharing a new batch. If you want your patch included you
must submit it via the linked form.

Thanks to Vedant Kumar for giving feedback on last week's patch. I've
had no
new submissions this week, but Nikolai Kosjar is still [looking for
reviews](http://lists.llvm.org/pipermail/cfe-dev/2018-January/056493.html) on
[D39903](https://reviews.llvm.org/D39903) which allows pretty-printing of
declarations through the libclang API.