Alex Bradbury via llvm-dev
2020-Apr-06 19:04 UTC
[llvm-dev] LLVM Weekly - #327, Apr 6th 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).