[llvm-dev] LLVM Weekly - #272, March 18th 2019

[Alex Bradbury via llvm-dev]

LLVM Weekly - #272, March 18th 2019
===================================

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

Welcome to the two hundred and seventy-second 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

LLVM 8.0.0-rc5 [has been
tagged](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130919.html).

Aldy Hernandez
[blogged](https://developers.redhat.com/blog/2019/03/13/intro-jump-threading-optimizations/)
about jump threading optimisations in GCC.


## On the mailing lists

* Michael Platings
[reports](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130925.html) he
has collected together all feedback on the variable naming discussion into a
[provisional transition plan proposal](https://reviews.llvm.org/D59251). This
is a truly fantastic summary of the comments and viewpoints expressed during
the discussion so far that I'd strongly recommend reading.

* The discussion on [next steps for scalable vector types in
IR](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130852.html)
continues, with proposals for more discussions at EuroLLVM. Graham Hunter
[summarised](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130920.html)
the status from an Arm perspective. As an alternative to adding scalable
vectors as a first class type, they are considering using opaque types to
support C-language intrinsics and using fixed length autovectorisation for SVE
auto-vectorisation.

* Matthew Arsenault
[notes](http://lists.llvm.org/pipermail/llvm-dev/2019-March/131034.html) that
with the merging of support for the immarg attribute, in-tree and out-of-tree
backends should update intrinsics to use it.

* Arnaud Allard de Grandmaison is [looking for volunteer
moderators](http://lists.llvm.org/pipermail/llvm-dev/2019-March/131087.html)
for EuroLLVM 2019.

* Connor Kuehl posted an RFC on [implementing Randstruct support in
Clang](http://lists.llvm.org/pipermail/cfe-dev/2019-March/061607.html). This
is a compile-time hardening technique that randomizes the field layout of
structs.

* JF Bastien
[suggests](http://lists.llvm.org/pipermail/cfe-dev/2019-March/061669.html)
adding Clang macros for the revision number of commit hash of the built
compiler. Some responses are concerned about the impact on incremental build
times for developers.

* Sanjoy Das shared an RFC on [making space for a flush-to-zero flag in
FastMathFlags](http://lists.llvm.org/pipermail/llvm-dev/2019-March/131077.html).
He proposes four potential paths forward.

* Rodrigo Rocha is [seeking
feedback](http://lists.llvm.org/pipermail/llvm-dev/2019-March/131066.html) on
his proposed roadmap for improving function merging, based on his CGO'19 paper
"Function Merging by Sequence Alignment".

* Brian Gesiak
[suggests](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130956.html)
consolidating the functions that remove unreachable blocks
(EliminateUnreachableBlocks and removeUnreachableBlocks). As
removeUnreachableBlocks is more aggressive, this change would affect many
in-tree tests.

* "bd1976" kicked off an RFC discussion on [supporting ELF
autolinking](http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html).
This allows developers to specify linker inputs in their source code.

* Johannes Doerfert has now [shared an initial
implementation](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130967.html)
of late GPU "SPMD-zation".


## LLVM commits

* Documentation was added on how dbg.value intrinsics should be handled and
updated in optimised code. [r356041](https://reviews.llvm.org/rL356041).

* An immarg parameter attribute was introduced, indicating an intrinsic
parameter is required to be a simple constant.
[r355981](https://reviews.llvm.org/rL355981).

* The Support/Endian library gained support for endian-specific enums.
[r355812](https://reviews.llvm.org/rL355812).

* A bitset is now used for assembler predicates.
[r355839](https://reviews.llvm.org/rL355839).

* ESan (Efficiency Sanitizer) has been removed, as it hadn't reached a state
where it was widely useful and hasn't seen active development for some years.
ASan asm instrumentation was also removed.
[r355862](https://reviews.llvm.org/rL355862),
[r355870](https://reviews.llvm.org/rL355870).

* The handling of processor features in X86.td in the X86 backend has been
completely refactored, removing ProcModel and ProcFeatures in favour of a
ProcessorFeatures tablegen class.
[r355872](https://reviews.llvm.org/rL355872).

* A new MsgPackDocument class was added.
[r356080](https://reviews.llvm.org/rL356080).


## Clang commits

* A script was committed that invokes C-Reduce on an input file to produce a
minimal reproducer for Clang crashes.
[r355944](https://reviews.llvm.org/rL355944).

* The clangd fuzzy-matching algorithm was tweaked.
[r356261](https://reviews.llvm.org/rL356261).


## Other project commits

* LLDB gained the ability to import the std module into the expression parser
to improve C++ debugging. [r355939](https://reviews.llvm.org/rL355939).

* Deprecation warnings were changed to enabled by default in libcxx.
[r355961](https://reviews.llvm.org/rL355961).

* LLDB's DWARF parsing code was updated to return llvm::Error and
llvm:Expected. [r356190](https://reviews.llvm.org/rL356190),
[r356278](https://reviews.llvm.org/rL356278).