[llvm-dev] LLVM Weekly - #317, Jan 27th 2020

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 27 11:54:30 PST 2020


LLVM Weekly - #317, Jan 27th 2020
=================================

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

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

John Regehr wrote up [some opportunities for improving precision of LLVM's
demanded bits analysis](https://blog.regehr.org/archives/1714).

Minutes from recent LLVM Foundation board meetings [have now been
published](https://llvm.org/foundation/documents/).

Ying Yi wrote up an article on the SN Systems blog about [initial results from
the Program Repository research
project](https://www.snsystems.com/technology/tech-blog/llvm-build-times-using-a-program-repository).


## On the mailing lists

* Johannes Doerfert gave an [update on work to revisit
llvm.assume](http://lists.llvm.org/pipermail/llvm-dev/2020-January/138605.html),
highlighting patches that are up for review.

* Arnaud Allard de Grandmaison [responded to the RFC on creating on LLVM
security
group](http://lists.llvm.org/pipermail/llvm-dev/2020-January/138604.html) on
behalf of the LLVM Foundation Board.

* Lang Hames shares the [second installment of ORC JIT
Weekly](http://lists.llvm.org/pipermail/llvm-dev/2020-January/138584.html),
highlighting work to remove blockers for people transitioning from ORCv1 to
ORCv2.

* Florian Hahn started a discussion about [adding an in-tree helper script to
create/apply patches without
arc](http://lists.llvm.org/pipermail/llvm-dev/2020-January/138459.html).

* Prashanth N R reports [the open-source of the FC MLIR+LLVM based Fortran
frontend has
started](http://lists.llvm.org/pipermail/llvm-dev/2020-January/138555.html).

* Brian Gesiak [highlights outstanding LazyCallGraph patch
reviews](http://lists.llvm.org/pipermail/llvm-dev/2020-January/138491.html)
that are pre-requisites for his C++20 coroutines work using the new pass
manager.

* Leonard Chan [enquires about contributions to libcxxabi for different
ABIs](http://lists.llvm.org/pipermail/libcxx-dev/2020-January/000653.html). In
particular, the PC-relative vtable ABI implemented in Fuchsia.

* Nick Meyer is keen to [start a discussion on implementing the Reflect TS in
Clang](http://lists.llvm.org/pipermail/cfe-dev/2020-January/064424.html).

* Reid Kleckner shares a [proposal to replace the inalloca attribute with new
intrinsics and a new `preallocated`
attribute](http://lists.llvm.org/pipermail/llvm-dev/2020-January/138627.html).


## LLVM commits

* An `llvm.vscale` intrinsic was added.
[67d4c99](https://reviews.llvm.org/rG67d4c9924c1).

* Initial placeholder/infrastructure code for llvm-ml (a MASM assembler) was
committed. [5f6dfa8](https://reviews.llvm.org/rG5f6dfa800e0).

* A scheduler description was added for the Rocket RISC-V core.
[838a28e](https://reviews.llvm.org/rG838a28e234e).

* The Hexagon backend gained support for the Linux/Musl ABI and the
Hexagon/HVX v67 ISA. [7fee4fe](https://reviews.llvm.org/rG7fee4fed4c7),
[c12a591](https://reviews.llvm.org/rGc12a5917d2f).

* Support was added for the Hexagon v67t microarchitecture ("tiny core").
[305bf5b](https://reviews.llvm.org/rG305bf5b21db).

* The AMDGPU backend has new documentation for RegisterBankInfo, documenting
high level strategies that could be used for register bank selection.
[f6418d7](https://reviews.llvm.org/rGf6418d72f57).

* The VE backend development continues with support for new argument types,
return values, and consts, and setcc isel patterns, and much more in further
patches. [3a906a9](https://reviews.llvm.org/rG3a906a9f4e6),
[dc69265](https://reviews.llvm.org/rGdc69265eea8).

* `CreateAlignedLoad` was deprecated. This is part of work to introduce an
`Alignment` type. [279fa8e](https://reviews.llvm.org/rG279fa8e0064).

* The PowerPC backend gained support for prefixed instructions, to be utilised
on a future CPU. [5cee340](https://reviews.llvm.org/rG5cee34013cf).

* FileCheck now supports matching formats, which is part of a patch series
adding support for FileCheck numeric expressions.
[8e96697](https://reviews.llvm.org/rG8e96697c7df).

* The SILoadStoreOptimizer now does a better job at merging out of order
offsets. [86c944d](https://reviews.llvm.org/rG86c944d7907).


## Clang commits

* Support for placeholder constraints and abbreviated templates was added as
part of the ongoing C++ concepts implementation work.
[98ea4b3](https://reviews.llvm.org/rG98ea4b30c2c).

* The Arm MVE intrinsics were updated to work in C++.
[98ea4b3](https://reviews.llvm.org/rG98ea4b30c2c).

* `-fconcepts-ts` should no longer be used to enable Concepts. Instead,
support is enabled through `-std=c++2a`.
[67c608a](https://reviews.llvm.org/rG67c608a9695).

* clang-tidy headers are now included in the Clang distribution.
[301a437](https://reviews.llvm.org/rG301a437250b).


## Other project commits

* Benchmarking infrastructure was added for llvm-libc memory functions.
[aba80d0](https://reviews.llvm.org/rGaba80d0734d).

* The new lldb-repro utility can be used to transparently capture and replay
debugger sessions through the command line driver, and is used to test
reproducers. Documentation on the reproducer test strategy was also added.
[67420f1](https://reviews.llvm.org/rG67420f1b0e9),
[48490e3](https://reviews.llvm.org/rG48490e3247a).

* The libcxx test suite was updated to be compatible with Python 3.8.x.
[7b8dc8c](https://reviews.llvm.org/rG7b8dc8c5769).

* An initial doxygen config was added to the mlir subdirectory.
[e298e21](https://reviews.llvm.org/rGe298e216501).

* MLIR gained an `llvm.cmpxchg` operation as part of its LLVM dialect.
[fffea28](https://reviews.llvm.org/rGfffea2842d2).


More information about the llvm-dev mailing list