[llvm-dev] LLVM Weekly - #327, Apr 6th 2020

Mon Apr 6 12:04:23 PDT 2020

LLVM Weekly - #327, Apr 6th 2020
================================

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

Welcome to the three hundred and twenty-seventh 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

Bruce Dawson wrote a detailed blog post [analysing Chromium build
times](https://randomascii.wordpress.com/2020/03/30/big-project-build-times-chromium/).

Version 1.5 of pocl (Portable Computing Language) [has been
released](http://lists.llvm.org/pipermail/llvm-dev/2020-April/140605.html). Is
adds support for Clang/LLVM 10.0, a kernel profiling feature, and various
fixes and performance improvements.

A new version of JLang, a Java-to-LLVM ahead-of-time compiler [has been
released](http://lists.llvm.org/pipermail/llvm-dev/2020-March/140521.html). It
supports all Java 7 language features except for some reflection support.

## On the mailing lists

* The fourth MLIR (bi)weekly newsletter [is now
available](https://llvm.discourse.group/t/mlir-news-4th-edition-4-3-2020/755),
offering the usual mix of development highlights.

* Ten Tzen shared an RFC on [completing support for windows structured
exception
handling](http://lists.llvm.org/pipermail/llvm-dev/2020-March/140541.html) by
implementing support for catching hardware exceptions and local unwind. Reid
Kleckner [suggested separating consideration of the two
features](http://lists.llvm.org/pipermail/llvm-dev/2020-April/140615.html).

* ORC JIT Weekly #10 [is
out](http://lists.llvm.org/pipermail/llvm-dev/2020-April/140673.html),
covering interpose fixes and universal binary support.

* Jon Roelofs shared ideas on [improving
FileCheck](http://lists.llvm.org/pipermail/llvm-dev/2020-April/140610.html),
highlighting areas where current FileCheck usage may silently hide failures.

* Gauthier proposed [removing the use of the waymarking algorithm from
Use](http://lists.llvm.org/pipermail/llvm-dev/2020-April/140542.html). This
increases peak memory usage slightly but also slightly improves compile time.
Responses so far are in favour as long as nobody has strong arguments for
retaining it.

* Sander De Smalen highlighted that [biweekly LLVM SVE/SVE2 sync up calls are
taking place every other
Thursday](http://lists.llvm.org/pipermail/llvm-dev/2020-April/140555.html).

* Sebastian Perta has been writing an LLVM backend for the Renesas RL78 MCU
and is [seeking
feedback](http://lists.llvm.org/pipermail/llvm-dev/2020-April/140546.html) on
questions such as supporting C language extensions from the Renesas RL78
commercial compiler.

* River Riddle has [written a Chrome extensions to monitor the status of code
reviews on LLVM
phabricator](http://lists.llvm.org/pipermail/llvm-dev/2020-March/140484.html).

## LLVM commits

* Two passes were added to mitigate Load Value Injection (LVI) on X86. The
first replaces each indirect call/jump with a direct call to a thunk, while
the second replaces RET instructions with a new instruction sequence.
[5b519cf](https://reviews.llvm.org/rG5b519cf1fc6),
[f95a67d](https://reviews.llvm.org/rGf95a67d8b8a).

* Loop Closed SSA Form was explained as part of LLVM's loop terminology
documentation. [229cda9](https://reviews.llvm.org/rG229cda968cb).

* The semantics of branch on undef were clarified in the language reference
doc. [05f0e59](https://reviews.llvm.org/rG05f0e598ab2).

* The UnifyLoopExits pass was added, and an option was added to the AMDGPU
backend to use it. [3cbbded](https://reviews.llvm.org/rG3cbbded68c2).

* Support was added for emitting and parsing ELF attribute sections for
RISC-V. This extracted common parsing logic from the existing Arm ELF
attribution section support.
[581ba35](https://reviews.llvm.org/rG581ba35291a),
[501522b](https://reviews.llvm.org/rG501522b5b2a).

* The style for error and warning messages was documented.
[6aacdd6](https://reviews.llvm.org/rG6aacdd6083d).

* The waymarking algorithm (allowing backtracing an arrays head from a pointer
into it) was implemented as a utility in LLVM's ADT library.
[154d517](https://reviews.llvm.org/rG154d517bc7d).

* llvm-dwarfdump gained a new `--show-sections-sizes` option which will print
the number of bytes within the debug sections.
[5e508b9](https://reviews.llvm.org/rG5e508b9bac0).

* It's now possible for lit.site.cfg to contain relative paths, which provides
greater support for building on one machine and running the test on another.
[fb80b6b](https://reviews.llvm.org/rGfb80b6b2d58).

## Clang commits

* clangd now enables a set of clang-tidy checks by default.
[164ed7b](https://reviews.llvm.org/rG164ed7b1d04).

* Initial support was added for OpenMP 5.0 iterator expressions.
[13a1504](https://reviews.llvm.org/rG13a1504ffb9).

## Other project commits

* The new LLD Mach-O backend has started to land.
[03f43b3](https://reviews.llvm.org/rG03f43b3aca3).

* The Dexter-based debuginfo regression suite now supports Windows.
[b6d2212](https://reviews.llvm.org/rGb6d2212f527).

* The MLIR subproject added a tablegen backend for defining Pass information.
[8155e41](https://reviews.llvm.org/rG8155e41ac61),
[e3d834a](https://reviews.llvm.org/rGe3d834a54af),
[3dddd89](https://reviews.llvm.org/rG3dddd8969f4),
[9a277af](https://reviews.llvm.org/rG9a277af2d42),
[9be4be3](https://reviews.llvm.org/rG9be4be3e532).

* LLVM's libc gained a strlen implementation.
[1fcfd30](https://reviews.llvm.org/rG1fcfd30fae7).

* An alternative Lit test format was added for libcxx tests with the goal of
making it easier to run the tests on an embedded device or build with a
specific SDK. [80a2ddf](https://reviews.llvm.org/rG80a2ddf65cc).

* MLIR now has an example of a minimal out-of-tree dialect implementation.
[160f5aa](https://reviews.llvm.org/rG160f5aa65fa).