[llvm-dev] LLVM Weekly - #389, June 14th 2021

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 14 11:22:48 PDT 2021


LLVM Weekly - #389, June 14th 2021
==================================

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

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

Inspired by the recent thread on introducing a 'byte' type to LLVM IR, Nicolai
Hähnle blogged about [the challenges of implementing memcpy in LLVM
IR](https://nhaehnle.blogspot.com/2021/06/can-memcpy-be-implemented-in-llvm-ir.html)

The competition to build Clang and LLVM in the fastest time possible
continues, with Takumi Nakamura [demonstrating a build in under
60s](https://twitter.com/chapuni/status/1401519362058555393) on the AWS
c5a.24xlarge.

Herb Sutter wrote up a [trip report from the Summer 2021 ISO C++ standard
meeting](https://herbsutter.com/2021/06/09/trip-report-summer-2021-iso-c-standards-meeting-virtual/).


## On the mailing lists

* Reid Kleckner kicked off an RFC thread on [revisiting the LLD-as-a-library
  design](https://lists.llvm.org/pipermail/llvm-dev/2021-June/151031.html).
  There is broad support for making LLD usable as a library, with a few
  concerns about how this might impact the work-in-progress MachO linker.

* Chris Lattner [shared some
  thoughts](https://lists.llvm.org/pipermail/llvm-dev/2021-June/150995.html)
  about the recent [blog post on design issues in LLVM
  IR](https://www.npopov.com/2021/06/02/Design-issues-in-LLVM-IR.html).

* Philip Reames followed up on the thread on moving to Discourse, [sharing
  thoughts](https://lists.llvm.org/pipermail/llvm-dev/2021-June/150999.html)
  on the potential drawbacks of this move.

* Anastasia Stulova
  [proposes](https://lists.llvm.org/pipermail/cfe-dev/2021-June/068318.html)
  changing the default version for OpenCL kernel compilation to OpenCL 1.2
  (from 1.0).

* Nicolai Hähnle
  [responded](https://lists.llvm.org/pipermail/llvm-dev/2021-June/151060.html)
  to the thread on introducing a byte type to LLVM, providing a summary of the
  issues.

* Ellis Hoag shared an RFC on [adding MachineIR
  Profile](https://lists.llvm.org/pipermail/llvm-dev/2021-June/151086.html), a
  new instrumentation pass that can produce optimisation profiles with a focus
  on binary size and runtime performance of the instrumented binaries.

* Necip Yildiran posted an RFC on [computing, storing, and restoring
  conservative call graphs with
  LLVM](https://lists.llvm.org/pipermail/llvm-dev/2021-June/151044.html). The
  goal is to store sufficient information to allow the call graph to be
  constructed while source information is present, and store it in a non-code
  section of the binary.

* Sameer Sahasrabuddhe responded to the previous thread about abstracting
  over SSA form IRs to implement generic analyses with [some statistics on the
  performance cost of introducing virtual
  calls](https://lists.llvm.org/pipermail/llvm-dev/2021-June/150990.html).


## LLVM commits

* A function specialisation pass was added. As explained in the commit
  message, it isn't yet enabled by default but the hope is to enable it for
  `-O3` and above in order to close the gap for a number of benchmarks where
  GCC produces better code than LLVM.
  [c4a0969](https://reviews.llvm.org/rGc4a0969b9c14).

* A post-processing step was added for block frequency info inference in order
  to correctly handle CFGs with irreducible loops.
  [0a0800c](https://reviews.llvm.org/rG0a0800c4d10c).

* A new option was added to the CFGPrinter to hide 'cold' blocks from the
  emitted graph. [9197bac](https://reviews.llvm.org/rG9197bac297f7).

* LLVM's Sequence type is now reverse-iterable.
  [e056903](https://reviews.llvm.org/rGe0569033e21d).


## Clang commits

* The C++ P1099 "using enum" proposal was implemented.
  [012898b](https://reviews.llvm.org/rG012898b92cad),
  [b2d0c16](https://reviews.llvm.org/rGb2d0c16e91f3).

* The OpenMP `#pragma omp unroll` directive was implemented.
  [a222361](https://reviews.llvm.org/rGa22236120f17).

* A status page for tracking C proposals was added.
  [3a7a774](https://reviews.llvm.org/rG3a7a77494178).


## Other project commits

* Fixed-width literal and cstring deduplication was implemented in the MachO
  linker. [04259cd](https://reviews.llvm.org/rG04259cde15a9),
  [5d88f2d](https://reviews.llvm.org/rG5d88f2dd9478).

* mlir-lsp-server now supports textDocument/documentSymbols, allowing for easy
  navigation to functions/modules.
  [ff81a2c](https://reviews.llvm.org/rGff81a2c95ddb).

* The `alloca_scope` op was added to MLIR.
  [fdc0d43](https://reviews.llvm.org/rGfdc0d4360b4e).

* Patches implementing OMPD (an OpenMP debugging interface) started to land.
  [f61602b0](https://reviews.llvm.org/rGf61602b0d3fd).

* Scudo was extended to support [Trusty
  OS](https://source.android.com/security/trusty).
  [2551053](https://reviews.llvm.org/rG2551053e8d8d).

* LLVM's libc gained an implementation of expm1f.
  [4e5f8b4](https://reviews.llvm.org/rG4e5f8b4d8d9d).

* range.subrange was added to libcxx.
  [9106047](https://reviews.llvm.org/rG9106047ee3dd).


More information about the llvm-dev mailing list