[llvm-dev] LLVM Weekly - #419, January 10th 2022

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 10 12:57:38 PST 2022 

On Mon, 10 Jan 2022 at 19:40, Alex Bradbury <asb at asbradbury.org> wrote:
>
> LLVM Weekly - #419, January 10th 2022
> =====================================
>
> If you prefer, you can read a HTML version of this email at
> <http://llvmweekly.org/issue/419>.
>
> Welcome to the four hundred and nineteenth 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
>
> Even more recordings from the 2021 LLVM Developers' Meeting [are now
> available](https://www.youtube.com/playlist?list=PL_R5A0lGi1AATJX6-tY7IkYjpRjv30ziN).
> A [tutorial on ORCv2 from the
> meeting](https://www.youtube.com/watch?v=i-inxFudrgI) has also been published.
>
> Arseny Kapoulkine [blogged about Proebsting's
> Law](https://zeux.io/2022/01/08/on-proebstings-law/), putting it to test using
> LLVM and Clang (is it really the case that compiler advances double computing
> power every 18 years?). The overall conclusion was "LLVM 11 tends to take 2x
> longer to compile code with optimizations, and as a result produces code that
> runs 10-20% faster (with occasional outliers in either direction), compared to
> LLVM 2.7 which is more than 10 years old."
>
>
> ## On the mailing lists
>
> * Tanya Lattner posted about [LLVM's move to
>   Discourse](https://lists.llvm.org/pipermail/llvm-dev/2022-January/154582.html).
>   There is also an [accompanying blog
>   post](https://blog.llvm.org/posts/2022-01-07-moving-to-discourse/) and
>   [migration guide](https://llvm.org/docs/DiscourseMigrationGuide.html). In
>   the posted timeline, the mailing lists will be put into read-only mode from
>   February 1st and the archives migrated into Discourse between January 10th
>   and January 20th. People are encouraged to use Discourse rather than the
>   mailing list from January 10th onwards. This might be the last LLVM Weekly
>   posted to llvm-dev. Remember, you can always [subscribe at
>   llvmweekly.org](https://llvmweekly.org/) too.
>
> * Tom Stellard shared that [a system is now in place for subscribing to GitHub
>   issue
>   labels](https://lists.llvm.org/pipermail/llvm-dev/2022-January/154537.html).
>   Simply request membership of the appropriate issue-subscribers-$LABEL_NAME
>   team. As discussed in the thread, it's not immediately obvious where to find
>   the "Request to join button". You need to click on the team, then click
>   "Members", then you'll see the necessary button.
>
> * Augie Fackler posted an RFC on [adding support for marking allocator
>   functions in LLVM
>   IR](https://lists.llvm.org/pipermail/llvm-dev/2022-January/154599.html). The

Apologies, the link should be
https://lists.llvm.org/pipermail/llvm-dev/2022-January/154538.html

>   intent is to better support languages like Rust that have allocator
>   functions with symbol names that aren't recognised by LLVM as the libc
>   allocator functions are. This generated a fair amount of discussion, for
>   instance [this question from Philip
>   Reames](https://lists.llvm.org/pipermail/llvm-dev/2022-January/154557.html).
>
> * Stella Stamenova kicked off a discussion about [the responsibilities of a
>   buildbot
>   owner](https://lists.llvm.org/pipermail/llvm-dev/2022-January/154587.html),
>   especially around where responsibility lies when there are flaky tests.
>
> * Anastasia Stulova posted an RFC on [supporting linking of SPIR-V object
>   files using spirv-link from the SPIRV-Tools
>   project](https://lists.llvm.org/pipermail/cfe-dev/2022-January/069658.html).
>
> * Stefan Gränitz provided an [overview of missing RISC-V functionality in
>   LLVM's JIT
>   libraries](https://lists.llvm.org/pipermail/llvm-dev/2022-January/154517.html).
>
> * Serge Guelton [advertised an upcoming change to the AttrBuilder
>   API](https://lists.llvm.org/pipermail/llvm-dev/2022-January/154549.html)
>   intended to reduce the performance overhead.
>
> * Tom Stellard [updated on the status of the 13.0.1
>   release](https://lists.llvm.org/pipermail/llvm-dev/2022-January/154586.html),
>   noting rc2 is due on Monday (today) and will hopefully be the last release
>   candidate.
>
> * Kito Cheng and Jessica Clarke [invited the LLVM community to review v1.0-rc1
>   of the RISC-V
>   psABI](https://lists.llvm.org/pipermail/llvm-dev/2022-January/154599.html).
>   As noted in the email, this release is intended to mark a stable milestone,
>   but future backwards-compatible changes or wording improvements will still
>   be accepted and incorporated into future releases.
>
> * Tom Stellard picked up an old thread on automating releases with a [tweaked
>   suggestion](https://lists.llvm.org/pipermail/llvm-dev/2022-January/154583.html),
>   proposing that testers upload directly to GitHub (and also email the sha512
>   hash), and Tom later signs the binaries.
>
>
> ## LLVM commits
>
> * MC layer support was added for the armv8.8-a hinted branch instruction and
>   memcpy/memset acceleration instructions.
>   [8c1e520](https://reviews.llvm.org/rG8c1e520c903e),
>   [e35a3f1](https://reviews.llvm.org/rGe35a3f188f6a).
>
> * As part of the opaque pointer type transition, indirect inline asm operands
>   now take an elementtype attribute.
>   [8484bab](https://reviews.llvm.org/rG8484bab9cd5e),
>   [f430c1e](https://reviews.llvm.org/rGf430c1eb6443),
>   [eddd5be](https://reviews.llvm.org/rGeddd5be1df06).
>
> * Codegen for select/br/cmp as well as frame lowering infrastructure was added
>   to the CSKY backend. [9566cf1](https://reviews.llvm.org/rG9566cf16ad39).
>
> * A new pass was added to the RISC-V backend to replace redundant sext.w
>   instructions with copies on RV64.
>   [56ca11e](https://reviews.llvm.org/rG56ca11e31e6a).
>
> * A Discourse migration guide was committed.
>   [645c845](https://reviews.llvm.org/rG645c845d45ae).
>
>
> ## Clang commits
>
> * clang-format now accepts an option to explicitly specify a configuration
>   file. [b9e173f](https://reviews.llvm.org/rGb9e173fcd46b).
>
> * `__builtin_trap` and `__builtin_debugtrap` were documented.
>   [491984c](https://reviews.llvm.org/rG491984c4e60c).
>
>
> ## Other project commits
>
> * `std::basic_string::resize_and_overwrite` was implemented in libcxx.
>   [bec50db](https://reviews.llvm.org/rGbec50db2edf6).
>
> * Using llvm-config to detect the LLVM installation is now deprecated in LLD's
>   CMake build system. [a1da5f3](https://reviews.llvm.org/rGa1da5f3c2d65).
>
> * Summary formatters were added to LLDB for libcxx std::string_view.
>   [7244e9c](https://reviews.llvm.org/rG7244e9c2f5f3).
>
> * LLDB's data formatter documentation was expanded.
>   [69c8e64](https://reviews.llvm.org/rG69c8e64ba6be).
>
> * A script was added to run clang-tidy on the whole MLIR codebase.
>   [590a62d](https://reviews.llvm.org/rG590a62d1b253).
>
> * C and Python bindings were added for the MLIR quantization dialect types.
>   [9bcf13b](https://reviews.llvm.org/rG9bcf13bf3e63),
>   [66d4090](https://reviews.llvm.org/rG66d4090d9b15).

More information about the llvm-dev mailing list