[llvm-dev] LVM Weekly - #270, March 4th 2019

[Alex Bradbury via llvm-dev]

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)