[llvm-dev] LLVM Weekly - #249, October 8th 2018
Alex Bradbury via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 8 10:15:39 PDT 2018
LLVM Weekly - #249, October 8th 2018
=====================================
If you prefer, you can read a HTML version of this email at
<http://llvmweekly.org/issue/249>.
Welcome to the two hundred and forty-ninth 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
Videos are
[now available](https://www.youtube.com/playlist?list=PLOGTP9W1DX5VSSCvk_OApXX_Zil1F87s-)
from the GNU Tools Cauldron 2018.
The [LLVM Dev Meeting 2018](http://llvm.org/devmtg/2018-10/) is taking place
next week. I hope to see many of you there. I'll be giving a tutorial on LLVM
backend development (using RISC-V as an example of course) and running a
RISC-V LLVM backend coding lab session.
## On the mailing lists
* Kristof Beyls kicked off a discussion on the [LLVM bug
lifecycle](http://lists.llvm.org/pipermail/llvm-dev/2018-October/126732.html)
in preparation for the birds of a feather session at the LLVM Dev Meeting next
week. He proposes several actions that would hopefully improve the bugzilla
experience for LLVM developers and bug submitters.
* Tom Stellard proposes the [release schedule for LLVM
7.0.1](http://lists.llvm.org/pipermail/llvm-dev/2018-October/126602.html). In
this schedule, 7.0.1 would be released on December the 5th.
* Jonas Devlieghere posted an RFC on [moving clang's Virtual File System
infrastructure to
LLVM](http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html). This
would allow it to be used by LLDB when implementing support for "reproducers".
* Tanya Lattner is [looking for
moderators](http://lists.llvm.org/pipermail/llvm-dev/2018-October/126713.html)
for the LLVM Dev Meeting next week.
* Frank Schaefer is looking for feedback on an RFC to [rearchitect the GNU
toolchain driver support in
Clang](http://lists.llvm.org/pipermail/llvm-dev/2018-October/126701.html),
with the motivation of simplifying multilib support.
* Chandler Carruth provided feedback in the thread discussing [implementing
OptBisect for the new pass
manager](http://lists.llvm.org/pipermail/llvm-dev/2018-October/126719.html).
This generated a number of further responses, with LLVM developers sharing how
opt-bisect currently fits into their workflow.
* Thomas Lively [proposes new floating point minimum and maximum
intrinsics](http://lists.llvm.org/pipermail/llvm-dev/2018-October/126664.html),
matching the operations defined in the draft IEEE754-2018 draft standard.
* Zachary Turner [proposes replacing all LLDB PDB code with a non-Windows
specific
implementation](http://lists.llvm.org/pipermail/lldb-dev/2018-October/014215.html).
As explained in the RFC, LLVM currently supports parsing PDB files but LLDB
makes use of native (Windows-only) APIs instead. Zachary proposes porting LLDB
to use the low-level API in LLVM, rather than trying to provide LLDB's current
PDB API as a layer on top of it.
* Alex Bradbury created an RFC thread seeking feedback on [two different
implementation approaches to 64-bit RISC-V
support](http://lists.llvm.org/pipermail/llvm-dev/2018-October/126690.html).
As described in the RFC, the cleanest is to make full use of TableGen's
variable-sized register class support and have i64 as the only legal type.
This exposes several areas where new target hooks can improve the quality of
generated code. Feedback so far has been positive on this approach, rather
than modelling i32 subregs.
## LLVM commits
* WebAssembly was promoted from an experimental target.
[r343746](http://reviews.llvm.org/rL343746).
* `-time-passes` was implemented for the new pass manager.
[r343898](http://reviews.llvm.org/rL343898).
* The RISC-V backend gained support for named CSRs (system registers as
defined in the spec). [r343822](http://reviews.llvm.org/rL343822).
* The X86, AArch64 and ARM backends will no longer attach a debug location to
spill/reload instructions on the basis that they have no relation to the
original source code. [r343895](http://reviews.llvm.org/rL343895).
* GlobalISel gained new combiner helpers for extending loads, which are put to
use in an AARch64 pre-legalize combiner.
[r343564](http://reviews.llvm.org/rL343564).
* Instructions and registers from AArch64 v8.5A Memory Tagging Extension are
now recognised by the MC layer.[r343570](http://reviews.llvm.org/rL343570),
[r343571](http://reviews.llvm.org/rL343571),
[r343572](http://reviews.llvm.org/rL343572).
* llvm-mca learned to check if a register move can by eliminated by the
underlying physical register file.
[r343691](http://reviews.llvm.org/rL343691).
* The enableMultipleCopyHints hook was removed, as multiple regalloc hints are
always enabled. [r343851](http://reviews.llvm.org/rL343851).
## Clang commits
* The Clang Windows getting started documentation was updated.
[r343809](http://reviews.llvm.org/rL343809).
* ASan can now be used with MinGW.
[r343437](http://reviews.llvm.org/rL343537).
## Other project commits
* LLDB learned to fill backtraces with artificial tail call frames when
appropriate. [r343900](http://reviews.llvm.org/rL343900).
* libcxx is now tracking upcoming meeting papers / issues for the San Diego
C++ standard meeting. [r343923](http://reviews.llvm.org/rL343923).
More information about the llvm-dev
mailing list