Alex Bradbury via llvm-dev
2017-Dec-11 21:39 UTC
[llvm-dev] LLVM Weekly - #206, Dec 11th 2017
LLVM Weekly - #206, Dec 11th 2017
================================
If you prefer, you can read a HTML version of this email at
<http://llvmweekly.org/issue/206>.
Welcome to the two hundred and sixth 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
LLVM 5.0.1-rc3 [has been
tagged](http://lists.llvm.org/pipermail/llvm-dev/2017-December/119613.html).
The release should take place this week.
Madhur Amilkanthwar has written a simple [LLVM metadata
visualizer](https://github.com/madhur13490/LLVM-Metadata-Visualizer) using
dot.
## On the mailing lists
* Hans Wennborg has started the discussion on the [scheduling of the 6.0.0
release](http://lists.llvm.org/pipermail/llvm-dev/2017-December/119554.html).
Following the regular schedule, it would be branched on Wednesday 17th
January. One large consumer of the branch has requested it takes place earlier
to better align with their internal process, and Hans is seeking feedback on
this.
* Hideki Saito has shared a [status update on
VPlan](http://lists.llvm.org/pipermail/llvm-dev/2017-December/119522.html),
the effort to improve the Loop Vectorizer. "We are currently at a point
where
we can slow down the refactoring effort for the purpose of expediting the big
functionality boost: outer loop vectorization -and by doing so encourage
more participation from the wider LLVM community in the refactoring effort to
expedite the overall transition to the VPlan framework." Hideki's
follow-up
RFC outlines the plan for [outer loop
vectorisation](http://lists.llvm.org/pipermail/llvm-dev/2017-December/119523.html).
* Julie Hockett has [proposed a clang-doc
tool](http://lists.llvm.org/pipermail/cfe-dev/2017-December/056203.html), a
documentation generator for C/C++ code supporting Doxygen-style markup.
* Joel E. Denny has shared an RFC on
[clacc](http://lists.llvm.org/pipermail/cfe-dev/2017-December/056222.html), a
project that extends clang with OpenACC support. It works by translating
OpenACC to OpenMP.
* Mikhail Zolotukhin kicked off a discussion on [reducing LLVM build times by
minimising
includes](http://lists.llvm.org/pipermail/llvm-dev/2017-December/119530.html).
* Rahul Chaudhry has shared an
[update](http://lists.llvm.org/pipermail/llvm-dev/2017-December/119618.html)
on efforts to reduce the size of the dynamic relocations section in position
independent executables.
* Dean Michael Berris has
[shared](http://lists.llvm.org/pipermail/llvm-dev/2017-December/119529.html)
an XRay-generated trace of a Clang invocation which can be opened in the
Chrome trace viewer. Dean hopes such instrumentation will be useful for Clang
and LLVM development.
## LLVM commits
* Loop predication is now enabled for reverse loops.
[r319659](http://reviews.llvm.org/rL319659).
* Initial support for a hardware-assisted AddressSanitizer has been added. As
described in the [design
doc](https://reviews.llvm.org/source/clang/browse/cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst),
this is based around embedding metadata in pointers as supported on AArch64.
[r320217](http://reviews.llvm.org/rL320217).
* All outstanding MC-layer patches for RV{32,64}IMAFD support in the RISC-V
backend have now been committed, as well as initial MC layer support for the
compressed (C) instruction set extension.
[r320020](http://reviews.llvm.org/rL320020),
[r320023](http://reviews.llvm.org/rL320023),
[r320037](http://reviews.llvm.org/rL320037), and more.
* The Nios2 backend continues to develop, and now has enough infrastructure to
compile a simple empty function. [r320035](http://reviews.llvm.org/rL320035).
* The machine basic block reference format has been changed to unify output
between MIR and debug output. A line previously printed with the comment
"BB#0" will now be annotated with "%bb.0".The commit
messages contains a
series of shell commands that can be used to update tests and the like.
[r319665](http://reviews.llvm.org/rL319665).
* The register allocator can now generate and store multiple regalloc hints
per virtual register. This results in codegen improvements but must be enabled
on a per-target basis (due to the churn in tests).
[r319754](http://reviews.llvm.org/rL319754).
* guessInstructionProperties=0 is now set for the SystemZ backend. As noted in
the commit message, bugs were exposed in the process. See
[here](http://lists.llvm.org/pipermail/llvm-dev/2017-November/119069.html) for
more info on guessInstructionProperties and consider enabling it for your
backend! [r319756](http://reviews.llvm.org/rL319756).
* "Full coverage" of MC encoding for the X87 and FMA instructions for
X86 has
been added. [r320015](http://reviews.llvm.org/rL320015),
[r320016](http://reviews.llvm.org/rL320016).
* It is now possible to ask the tablegenerated register parsing function to
tolerate duplicate register names. This is useful for targets such as RISC-V
which use the same register names for 32 and 64-bit floating point.
[r320018](http://reviews.llvm.org/rL320018).
* The "debugify" pass to test debug info preservation has been added.
[r320202](http://reviews.llvm.org/rL320202).
## Clang commits
* Clang's default C++ dialect is now gnu++14 rather than gnu++98.
[r320250](http://reviews.llvm.org/rL320250).
* A design document for an AddressSanitizer inspired hardware-assisted memory
safety tool has been committed. [r319684](http://reviews.llvm.org/rL319684).
## Other project commits
* Initial libFuzzer support for Fuchsia OS has been added.
[r320210](http://reviews.llvm.org/rL320210).
* LLD gained a detector for Cortex-A53 erratum 843419.
[r319780](http://reviews.llvm.org/rL319780),
[r319781](http://reviews.llvm.org/rL319781).
## Review corner
The LLVM Weekly review corner serves to highlight patches that are stuck
waiting awaiting review, or work from first-time contributors. See
[here](http://llvmweekly.org/reviewcorner) for more information and how to
submit you work for inclusion. Of course the hope is that highlighting these
patches will enable LLVM Weekly readers will step up and help to get them
merged. I'll be reporting back each week on any activity generated on these
patches, as well as sharing a new batch. If you want your patch included you
must submit it via the linked form.
No new patch submissions this week, but thanks to "Cameron", Hal
Finkel, and
Richard Smith for contributing review comments to last week's patches.
Nikolai
Kosjar is still looking for a code review of
[D39903](https://reviews.llvm.org/D39903).