Welcome to the two hundred and seventy-second 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

LLVM 8.0.0-rc5 has been tagged.

Aldy Hernandez blogged about jump threading optimisations in GCC.

Michael Platings reports he has collected together all feedback on the variable naming discussion into a provisional transition plan proposal. This is a truly fantastic summary of the comments and viewpoints expressed during the discussion so far that I'd strongly recommend reading.

The discussion on next steps for scalable vector types in IR continues, with proposals for more discussions at EuroLLVM. Graham Hunter summarised the status from an Arm perspective. As an alternative to adding scalable vectors as a first class type, they are considering using opaque types to support C-language intrinsics and using fixed length autovectorisation for SVE auto-vectorisation.

Matthew Arsenault notes that with the merging of support for the immarg attribute, in-tree and out-of-tree backends should update intrinsics to use it.

Arnaud Allard de Grandmaison is looking for volunteer moderators for EuroLLVM 2019.

Connor Kuehl posted an RFC on implementing Randstruct support in Clang. This is a compile-time hardening technique that randomizes the field layout of structs.

JF Bastien suggests adding Clang macros for the revision number of commit hash of the built compiler. Some responses are concerned about the impact on incremental build times for developers.

Sanjoy Das shared an RFC on making space for a flush-to-zero flag in FastMathFlags. He proposes four potential paths forward.

Rodrigo Rocha is seeking feedback on his proposed roadmap for improving function merging, based on his CGO'19 paper "Function Merging by Sequence Alignment".

Brian Gesiak suggests consolidating the functions that remove unreachable blocks (EliminateUnreachableBlocks and removeUnreachableBlocks). As removeUnreachableBlocks is more aggressive, this change would affect many in-tree tests.

"bd1976" kicked off an RFC discussion on supporting ELF autolinking. This allows developers to specify linker inputs in their source code.