Alex Bradbury via llvm-dev
2019-Mar-04 20:59 UTC
[llvm-dev] LVM Weekly - #270, March 4th 2019
LVM Weekly - #270, March 4th 2019 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/270>. Welcome to the two hundred and seventieth 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. There seems to have been a higher than usual volume of activity on the mailing lists this week. Apologies in advance if I missed anything! ## News and articles from around the web LLVM 8.0.0-rc3 [has been tagged](http://lists.llvm.org/pipermail/llvm-dev/2019-February/130613.html), source and binaries [are available](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130674.html). [JLang](https://polyglot-compiler.github.io/JLang/), a Java-to-LLVM ahead-of-time compiler [has been released](http://lists.llvm.org/pipermail/llvm-dev/2019-February/130474.html). ## On the mailing lists * Stephen Scalpone [kicked off an RFC thread](http://lists.llvm.org/pipermail/llvm-dev/2019-February/130497.html) on contributing 'f18' to the LLVM project. f18 is a ground-up rewrite of flang's codebase in modern C++. One of the issues discussed is that f18 currently uses C++17 features (which can't be used in LLVM as a whole until the minimum compiler versions are bumped sufficiently). Chandler Carruth is [concerned](http://lists.llvm.org/pipermail/llvm-dev/2019-February/130522.html) about the C++17 issue while Chris Lattner [sees no problem](http://lists.llvm.org/pipermail/llvm-dev/2019-February/130628.html). * Chris Lattner [summarises](http://lists.llvm.org/pipermail/cfe-dev/2019-February/061450.html) the potential advantages of adding a "Clang Intermediate Language (CIL)". * Peter Collingbourne [proposes](http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html) an LLD feature for automatically partitioning a program into multiple binaries. The post explains the potential advantages of this approach vs splitting using traditional ELF dynamic linking. * Sanjay Patel's [query](http://lists.llvm.org/pipermail/llvm-dev/2019-February/130491.html) on the interaction of funnel shift, select and poison triggered a large thread on poison and undef. One sub-thread discusses [the issue of poison in the SelectionDAG](http://lists.llvm.org/pipermail/llvm-dev/2019-February/130624.html). * Jan Korous shared an RFC on [upstreaming index-while-building functionality for clang](http://lists.llvm.org/pipermail/cfe-dev/2019-February/061432.html). Dmitri Gribenko [proposes](http://lists.llvm.org/pipermail/cfe-dev/2019-February/061462.html) unifying with the indexing implementation in clangd. * Shoaib Meenai [alerts us](http://lists.llvm.org/pipermail/cfe-dev/2019-February/061475.html) that the install-clang-headers target will soon be renamed to install-clang-resource-headers. * Hiroshi Yamauchi has authored an RFC on [getting ProfileSummaryInfo and BlockFrequencyInfo from various types of passes](http://lists.llvm.org/pipermail/llvm-dev/2019-February/130627.html) under the new pass manager. * Rui Ueyama is [seeking feedback](http://lists.llvm.org/pipermail/llvm-dev/2019-February/130565.html) on adding a linker option to dump the dependency graph for linking a binary. * David Greene [reports](http://lists.llvm.org/pipermail/llvm-dev/2019-February/130626.html) that he has now posted a version of his "system model" patch for review. * Zachary Turner [proposes](http://lists.llvm.org/pipermail/lldb-dev/2019-February/014763.html) moving LLDB debug info parsing out of process. A major identified advantage is this makes it possible to ultimately move debug info processing to a different machine entirely. * Philip Reames [announces](http://lists.llvm.org/pipermail/llvm-dev/2019-February/130612.html) that changes have been made to the handling of atomics in backends, and your out-of-tree backend may need to be updated. See the thread for a discussion of why the rationale behind the changes. ## LLVM commits * The first part of support for "context sensitive PGO" (CSPGO) was committed. With CSPGO, a second round of PGO is performed after inlining and indirect call promotion etc. See the commit message for further details. [r354930](https://reviews.llvm.org/rL354930). * A new order file instrumentation pass was added. This logs the execution ordering of functions, logging each function when it is first executed. [r355133](https://reviews.llvm.org/rL355133). * Basic support was added for the Cortex-A76, Cortex-A76AE, and Cortex-M35P. [r354788](https://reviews.llvm.org/rL354788), [r354868](https://reviews.llvm.org/rL354868). * The RegisterScavenger interface was extended to allow it to fail if a spill is required. [r354816](https://reviews.llvm.org/rL354816). * llvm-objdump gained support for `-M` target specific options, initially `-Mreg-names-raw/-std` for Arm. [r354870](https://reviews.llvm.org/rL354870). * Volatility and atomicity/ordering have been separated in SelectionDAG. i.e. atomic memory accesses are no longer necessarily volatile. This patch is intended to have no functional change, as for now LLVM will be as conservative for an atomic access as for a volatile access (though out-of-tree backends may want to check). [r355025](https://reviews.llvm.org/rL355025). ## Clang commits * clangd gained some more detailed documentation, with accompanying screenshots. [r354992](https://reviews.llvm.org/rL354992). * The WebAssembly Clang driver now uses `-matomics` rather than `-mthread-model`. [r351112](https://reviews.llvm.org/rL351112). * The Format library has itself been clang-formatted. [r355182](https://reviews.llvm.org/rL355182). ## Other project commits * The libcxx status page was updated with papers/issues from the Kona C++ standard meeting. [r354796](https://reviews.llvm.org/rL354796). * The LLDB reproducers effort is now at the point where interpreter commands can be captured and replayed. [r355249](https://reviews.llvm.org/rL355249)