[llvm-dev] LLVM Weekly - #264, January 21st 2019

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 21 11:44:57 PST 2019

LLVM Weekly - #264, January 21st 2019

If you prefer, you can read a HTML version of this email at

Welcome to the two hundred and sixty-fourth 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

The new license and developer policy [is now in
place](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129344.html). The
new license is now in place and all subsequent contributions to LLVM must be
under this license. The license for the LLVM-8 branch remains unchanged. See
the message for more information. Massive thanks are due to everyone involved.

LLVM 8.0.0 [has been
Trunk is now 9.0.0. 8.0.0 final is scheduled for Feb 27th.

Trail of Bits have an [incredibly in-depth blog
on how McSema handles C++ exceptions. As background, this includes a great
description of how C++ exceptions work.

## On the mailing lists

* Manman Ren has written an RFC on [generating order files for linker
The RFC describes an approach to log the execution order of functions, which
can be used to reduce application startup time.

* JF Bastien
a new toolchain update policy. "It's a new year, so let's try a new approach
in getting LLVM’s codebase past C++11. Instead of discussing toolchain
versions and whether C++14 or 17 is best, let's just focus on one baby step:
agreeing on a policy. This policy will be used to update our toolchain,
hopefully warning people in LLVM 8 and actually moving past C++11 for LLVM 9."
So far, there seems to be agreement on this step forwards.

* Yitzhak Mandelbaum now [has a
patch](http://lists.llvm.org/pipermail/cfe-dev/2019-January/060950.html) to
accompany his RFC on improving source-to-source transformations with clang.

* Kostya Serebryany has [shared
numbers](http://lists.llvm.org/pipermail/cfe-dev/2019-January/060878.html) for
the overhead of automatic variable initialisation on a large internal

* Anton Korobeynikov is [soliciting project
ideas](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129363.html) for
GSoC 2019.

* Chandler Carruth
renaming .TXT files to .txt. There are no major objections, though some
concerns about how well git/svn handle this on case insensitive filesystems.

* Ilya Biryukov started a [new
on improving/replacing the LLVM bug tracking workflow. James Y Knight
that discussions of moving issue tracking to GitHub are likely premature and
that there may be some straight-forward improvements that can be made to

* Kevin Neal is [seeking
input](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129229.html) from
LLVM language frontend maintainers (e.g. flang, Rust, Swift, Julia, ...). He
is adding IRBuilder APIs for constrained fadd and similar intrinsics and would
like to ensure they meet the needs of other frontend devs.

* Frej Drejhammar started an [RFC
thread](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129137.html) on
adding support for explicitly specifying calling convention details on-the-fly
in LLVM IR. Chris Lattner
this would be a good topic for a round table at EuroLLVM.

* Juneyoung Lee
adding new pointer manipulation intrinsics in order to reduce the number of
ptrtoint/inttoptr casts genereated by LLVM passes.

* Dylan McKay shared a [status
update](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129089.html) of
the AVR backend.

* Kostya Kortchinsky [shares
plans](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129113.html) for
the Scudo secure allocator to remain in the compiler-rt library, but made more
standalone (i.e. no `sanitizer_common` dependency).

## LLVM commits

* The new LLVM license structure and developer policy has been introduced.

* The getting started guide was updated to recommend the use of git over SVN.

* The Nios2 backend was removed. [r351231](https://reviews.llvm.org/rL351231).

* `no-frame-pointer-*` IR function attributes were replaced with
`frame-pointer`. [r351049](https://reviews.llvm.org/rL351049).

* A gn.py wrapper script was committed that adds `--dotfile=` and `--root=`
parameters. This is an alternative to moving the .gn file to the toplevel.

* As part of the ongoing move towards opaque pointer types, various IR APIs
were updated. [r351121](https://reviews.llvm.org/rL351121),

* Codegen support for the RV64A, atomics for RISC-V 64-bit was added. This
completes support for atomics lowering in accordance with the RISC-V memory
model, for 32- and 64-bit targets.

* Floating point types can now be used in `atomicrmw xchg`.

* Demangling support was added to llvm-readobj.

* The AbstractCallSite interface was introduced, acting as a unified interface
between (in)direct and callback calls.

## Clang commits

* A new attribute was added to opt specific functions out of speculative load
hardening. [r351565](https://reviews.llvm.org/rL351565).

* clangd gained an XPC transport layer for macOS.

* The UBSan alignment check learned to sanitizer `assume_aligned-like`
attributes. [r351177](https://reviews.llvm.org/rL351177).

* Clang now has an MSP430 toolchain description.

## Other project commits

* The compiler-rt CMakeLists.txt now has an option to disable the libc++
build. [r351117](https://reviews.llvm.org/rL351117).

* The openmp library received further OMPT 5.0 interface updates.

More information about the llvm-dev mailing list