[llvm-dev] LLVM Weekly - #228, May 14th 2018

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[llvm-dev] LLVM Weekly - #228, May 14th 2018

Muhui Jiang via llvm-dev
LLVM Weekly - #228, May 14th 2018

If you prefer, you can read a HTML version of this email at

Welcome to the two hundred and twenty-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](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 <[hidden email]>, or
@llvmweekly or @asbradbury on Twitter.

If you're interested in what went on at the RISC-V Workshop in Barcelona last
week, you might want to read my live blog for [day
and [day

## News and articles from around the web

[C++ Insights](https://github.com/andreasfertig/cppinsights) is a new
Clang-based tool by Andreas Fertig which tries to reveal the sort of "magic"
the compiler does behind the scenes, e.g. compiler provided functions or
automatic downcasts. It does this via a source-to-source transformation. Be
sure to check out the [online demo](https://cppinsights.io/).

The first LLVM social in Beijing will be held on [May

A new series of meetups in Sydney, Australia have been
The first meetup on May 31st features introductory talks on getting started
with LLVM. "This meetup is also a kick-off meetup for a series dedicated to
bringing more enthusiasts together and up to speed with the LLVM tools,
development process, and internals. We're also looking for interested
presenters and those with experience already working with the LLVM compiler

More videos have now been
[posted to YouTube](https://www.youtube.com/playlist?list=PL_R5A0lGi1AB3cJDXMAbl4qCq94QxEcSA)
from the recent EuroLLVM Developers' Meeting.

## On the mailing lists

* Tobias Edler von Koch has written an RFC on [(Thin)LTO with linker
building upon a presentation at the last US LLVM Developers' meeting. Tobias
summarises the aim: "The end goal of this effort is to extend the benefits of
(Thin)LTO, including significant code size and performance improvements, to
the many embedded and system-level software projects that rely on linker
scripts to control (ELF) image layout"

* The issue of the use of C++14 constructs in the implementation of LLVM
projects and the project build requirements is being revisited. JF Bastien
that with six months having past since the last discussion, perhaps now is the
time to look again at using C++14 in LLVM. He points out that WebKit,
Chromium, and Firefox are all moving or have already moved to C++14. Zachary
moving to C++17 directly to avoid future hassle. Erich Keane started a [new
thread](http://lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html) to
discuss a concrete policy on host compiler requirements, suggesting major
releases of host compilers (MSVC, GCC, Clang) from the past 3 years should be

* Sanjay Patel kicked off a thread on [performing reassociation optimisation
in LLVM IR](http://lists.llvm.org/pipermail/llvm-dev/2018-May/123117.html).

* In response to a [question from Jonas
Andrew Trick has given a really useful
[overview](http://lists.llvm.org/pipermail/llvm-dev/2018-May/123164.html) of
the design philosophy of the LLVM MachineScheduler.

* Jaseem Abid
moving llvm-emacs mode out of the LLVM repository and into its own git

* Andrea Di Biagio started an RFC thread on adding [MC support for variant
classes](http://lists.llvm.org/pipermail/llvm-dev/2018-May/123181.html). As
explained in that post, variant scheduling classes model situations where the
scheduling information differs depending on the values of the operands. Adding
support for representing this at the MC level would allow llvm-mca to
understand and resolve variant scheduling classes.

* Joel E. Denny
adding support to FileCheck for checking multiple occurrences of the same
string using CHECK-DAG. He later [follows
up](http://lists.llvm.org/pipermail/llvm-dev/2018-May/123258.html) with
further information and paths forward based on some initial implementation

## LLVM commits

* WebAssembly gained an initial disassembler.

* CodeGenPrepare was modified to split large data structures in the hope of
maximising the opportunity of merging offsets into the generated load/store
instructions. [r332015](https://reviews.llvm.org/rL332015).

* An initial version of the llvm-strip tool was introduced. This is ultimately
intended to be a drop-in replacement for binutils strip.

* DILabel metadata and the llvm.dbg.label intrinsic have been introduced to
LLVM. These allow debug info on labels to be emitted, which ultimately enables
debuggers to set breakpoints on labels.

* HexagonMCCodeEmitter was refactored to use data tables to handle fixups.

* The .option rvc/norvc directives are now supported in RISC-V assembly.

## Clang commits

* A large patch touching 14k lines removes all instances of `\brief` commands
in Doxygen comments. Doxygen is run with autobrief, so these markers are
unnecessary. [r331834](https://reviews.llvm.org/rL331834).

* Clang codegen has been implemented for the proposed C++2a comparison
operator. [r331677](https://reviews.llvm.org/rL331677).

* `-foutline` is now `-moutline`.

* Support was added for the `no_stack_protector` attribute.

* New `atomic_fetch_{min,max,umin,umax}` intrinsics were added.

## Other project commits

* compiler-rt gained an experimental data flow tracer for fuzz targets.

* Basic compiler-rt builtins were added for the Hexagon target.
LLVM Developers mailing list
[hidden email]