[llvm-dev] LLVM Weekly - #291, July 29th 2019

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 29 05:58:42 PDT 2019


LLVM Weekly - #291, July 29th 2019
==================================

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

Welcome to the two hundred and ninety-first 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

Botond Ballo has written up a [trip report from the Cologne C++ standards
meeting](https://botondballo.wordpress.com/2019/07/26/trip-report-c-standards-meeting-in-cologne-july-2019/).
You might also be interested in the results of [Herb Sutter's survey to find
the top five ISO C++ feature
proposals](https://herbsutter.com/2019/07/25/survey-results-your-top-five-iso-c-feature-proposals/).


## On the mailing lists

* The discussion on changing variable naming rules in LLVM spawned a
sub-thread on the interaction with git blame, with Chris Lattner giving
[further
insight](http://lists.llvm.org/pipermail/llvm-dev/2019-July/134199.html) into
why he now prefers a sweeping change and his concerns about avoiding codebase
improvements due to concerns about history.

* Andrew Wei has been [adding GlobalISel support to the RISC-V
backend](http://lists.llvm.org/pipermail/llvm-dev/2019-July/134146.html) and
iss seeking feedback.

* Hans Wennborg
[reports](http://lists.llvm.org/pipermail/llvm-dev/2019-July/134175.html) that
9.0.0-rc1 is coming a little bit later than expected, but should appear soon.

* Paul Kirth
[proposes](http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) a
new clang-mispredict tool that would identify and warn on potentially
incorrect uses of `__builtin_expect()`. The tool would be built on top of the
PGO infrastructure.

* Jon Korous [shares an
RFC](http://lists.llvm.org/pipermail/cfe-dev/2019-July/062973.html) on adding
frontend insight remarks to Clang, e.g. to explicitly indicate when implict
constructors are generated.


## LLVM commits

* Arm MVE codegen support continues, with the addition of MVE predicate
register support. [r366890](https://reviews.llvm.org/rL366890).

* LLVM's documentation gained definitions of commonly used terminology related
to loops. [r366960](https://reviews.llvm.org/rL366960).

* SanitizerCoverage has been ported to the new pass manager (the patch
re-landed). [r367053](https://reviews.llvm.org/rL367053).

* The Attributor can now deduce the "dereferenceable" attribute.
[r366788](https://reviews.llvm.org/rL366788).

* TargetLowering gained a SimplifyMultipleUseDemandedBits function, which can
peek through operations that contribute to the demanded bits of a node.
[r366799](https://reviews.llvm.org/rL366799).

* The PowerPC backend now has a new peephole to remove redundant load
immediate instructions. [r366840](https://reviews.llvm.org/rL366840).

* Basic definitions were added for the Cortex-A64, Cortex-A65AE, Neoverse E1
and Neoverse N1. [r367007](https://reviews.llvm.org/rL367007).

## Clang commits

* Clang now implements P1771, `[[nodiscard]]` for constructors.
[r367027](https://reviews.llvm.org/rL367027).

* firstprivate OpenMP variables are now supported.
[r366689](https://reviews.llvm.org/rL366689).


## Other project commits

* LLVM's OpenMP implementation now has RISCV64 support.
[r367021](https://reviews.llvm.org/rL367021).

* The libc++ std::vector implementation was updated to workaround suboptimal
codegen for `vector<unsigned char>`.
[r367183](https://reviews.llvm.org/rL367183).

* The libc++ c++2a status page was updated.
[r366696](https://reviews.llvm.org/rL366696).

* TableGen is now used to generate LLDB property definitions.
[r367058](https://reviews.llvm.org/rL367058).


More information about the llvm-dev mailing list