[llvm-dev] LLVM Weekly - #153, Dec 5th 2016

Mon Dec 5 03:01:06 PST 2016

LLVM Weekly - #153, Dec 5th 2016
================================

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

Welcome to the one hundred and fifty-third 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 at the fifth RISC-V Workshop in Mountain View last week. If you're
interested in what went on, you may want to check out my notes from [day
one](http://www.lowrisc.org/blog/2016/11/fifth-risc-v-workshop-day-one/) and
[day two](http://www.lowrisc.org/blog/2016/11/fifth-risc-v-workshop-day-two/).

## News and articles from around the web

Farzad Sadeghi has
[announced](http://lists.llvm.org/pipermail/cfe-dev/2016-December/051756.html)
[mutator](https://github.com/bloodstalker/mutator), a
[Misra-C](https://en.wikipedia.org/wiki/MISRA_C) 2004 checker.It is not yet
incomplete, but a number of rules have been implemented. The hope is that in
the future it will support code transformations as well.

The Zurich LLVM social will be held on [Thursday December
8th](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107566.html) at
ETH Zurch and will feature a talk 'Transparent Live Code Offloading on FPGA'
by Alberto Dassatti. Please register if you would like to attend.

## On the mailing lists

* Hal Finkel posted an RFC that [attempts to clarify LLVM/Clang's current
linkage behaviour and propose changes to make it more
consistent](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html).
In short, Clang will quite happily inline functions with global symbols, and
this means that techniques such as `LD_PRELOAD` to insert an alternative
implementation may not always work. Hal suggests keeping this behaviour as the
default.

* Dean Michael Berris has kicked off an RFC discussing [what functionality an
XRay library should
expose](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107664.html).
The main questions resolve around trace formats and backwards/forwards
compatibility requirements. Renato Golin's has a [thoughtful
response](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107665.html)
with some good examples of where other file formats have gone wrong.

* Bekket McClane has started a discussion on [parallelizing target-independent
instruction
selection](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107619.html).
He proposes an approach to parallelise selection in a fine-grained manner,
although the results so far are not promising. Some of following responses
[suggest](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107661.html)
there may not be much to be gained from parallelising this part of the
compilation process.

* Oren Ben Simhon has posted an RFC on [supporting the x86-64 vectorcall
calling
convention](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107679.html).
This uses more registers for arguments than the default or `__fastcall`
conventions.

* Francesco Petrogalli has shared
[details](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107666.html)
of some recent proposed patches to enable the vectorisation of loops that have
function calls to routines marked with `#pragma omp declare simd`.

## LLVM commits

* Compilation time of Chromium with CFI and UBSan has been substantially
improved through a new heuristic to handle regular expressions consisting of
simple wildcards. Before, compilation of Chromium's
`content_message_generator.cc` with CFI took 44 seconds, and it takes only 23
seconds after. [r288303](http://reviews.llvm.org/rL288303).

* Support for optimisation remarks was added to Global Value Numbering.
[r288370](http://reviews.llvm.org/rL288370).

* llvm-objdump now supports the wasm (Web Assembly) file format.
[r288251](http://reviews.llvm.org/rL288251).

* SystemZ has improved its use of conditional instructions and added support
for load-and-trap instructions. [r288028](http://reviews.llvm.org/rL288028),
[r288030](http://reviews.llvm.org/rL288030).

* The llvm-modextract tool was added. This is a simple tool for testing
features that rely on multi-module bitcode files. It will extract one of the
modules and write it to the output file.
[r288201](http://reviews.llvm.org/rL288201).

* Support has been committed for profile-based loop peeling. If the profiled
trip count is low, then peel the first several iterations.
[r288274](http://reviews.llvm.org/rL288274).

* The rules for reserved registers have been clarified.
[r288277](http://reviews.llvm.org/rL288277).

* FrameInstruction has been moved from MachineModuleInfo to MachineFunction.
This will require a trivial change for out-of-tree backends.
[r288291](http://reviews.llvm.org/rL288291).

## Clang commits

* Clang gained a whole bunch of unit tests for Linux distribution detection.
[r288062](http://reviews.llvm.org/rL288062).

* Support was added for constant expression evaluation of `wchar_t` versions
of simple string functions. [r288193](http://reviews.llvm.org/rL288193).

## Other project commits

* Identical code folding (ICF) in LLD has been parallelised. Because of this,
LLD can now link a 1.59GB chromium binary with ICF enabled in 10.28s, vs
40.94s for gold. The commit message includes a detailed discussion of the
algorithm used. This parallel ICF has also been ported to COFF, where the
Clang benchark goes from 11.73s to 6.94s vs 83.02s for MSVC link.
[r288373](http://reviews.llvm.org/rL288373).
[r288487](http://reviews.llvm.org/rL288487).

* The Scudo Hardened Allocator in compiler-rt now support 32-bit
architectures. [r288255](http://reviews.llvm.org/rL288255).

* libcxx gained an implementation of C++17 `<variant>`.
[r288547](http://reviews.llvm.org/rL288547).