[llvm-dev] LLVM Weekly - #272, March 18th 2019

Mon Mar 18 12:47:34 PDT 2019

On Mon, Mar 18, 2019 at 10:41 PM Alex Bradbury via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> LLVM Weekly - #272, March 18th 2019
> ===================================
>
> If you prefer, you can read a HTML version of this email at
> <http://llvmweekly.org/issue/272>.
>
> 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](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
>
> LLVM 8.0.0-rc5 [has been
> tagged](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130919.html).
-final (aka 8.0.0) was tagged today
https://lists.llvm.org/pipermail/llvm-dev/2019-March/131084.html

> Aldy Hernandez
> [blogged](https://developers.redhat.com/blog/2019/03/13/intro-jump-threading-optimizations/)
> about jump threading optimisations in GCC.
>
>
> ## On the mailing lists
>
> * Michael Platings
> [reports](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130925.html) he
> has collected together all feedback on the variable naming discussion into a
> [provisional transition plan proposal](https://reviews.llvm.org/D59251). 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](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130852.html)
> continues, with proposals for more discussions at EuroLLVM. Graham Hunter
> [summarised](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130920.html)
> 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](http://lists.llvm.org/pipermail/llvm-dev/2019-March/131034.html) 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](http://lists.llvm.org/pipermail/llvm-dev/2019-March/131087.html)
> for EuroLLVM 2019.
>
> * Connor Kuehl posted an RFC on [implementing Randstruct support in
> Clang](http://lists.llvm.org/pipermail/cfe-dev/2019-March/061607.html). This
> is a compile-time hardening technique that randomizes the field layout of
> structs.
>
> * JF Bastien
> [suggests](http://lists.llvm.org/pipermail/cfe-dev/2019-March/061669.html)
> 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](http://lists.llvm.org/pipermail/llvm-dev/2019-March/131077.html).
> He proposes four potential paths forward.
>
> * Rodrigo Rocha is [seeking
> feedback](http://lists.llvm.org/pipermail/llvm-dev/2019-March/131066.html) on
> his proposed roadmap for improving function merging, based on his CGO'19 paper
> "Function Merging by Sequence Alignment".
>
> * Brian Gesiak
> [suggests](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130956.html)
> 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](http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html).
> This allows developers to specify linker inputs in their source code.
>
> * Johannes Doerfert has now [shared an initial
> implementation](http://lists.llvm.org/pipermail/llvm-dev/2019-March/130967.html)
> of late GPU "SPMD-zation".
>
>
> ## LLVM commits
>
> * Documentation was added on how dbg.value intrinsics should be handled and
> updated in optimised code. [r356041](https://reviews.llvm.org/rL356041).
>
> * An immarg parameter attribute was introduced, indicating an intrinsic
> parameter is required to be a simple constant.
> [r355981](https://reviews.llvm.org/rL355981).
>
> * The Support/Endian library gained support for endian-specific enums.
> [r355812](https://reviews.llvm.org/rL355812).
>
> * A bitset is now used for assembler predicates.
> [r355839](https://reviews.llvm.org/rL355839).
>
> * ESan (Efficiency Sanitizer) has been removed, as it hadn't reached a state
> where it was widely useful and hasn't seen active development for some years.
> ASan asm instrumentation was also removed.
> [r355862](https://reviews.llvm.org/rL355862),
> [r355870](https://reviews.llvm.org/rL355870).
>
> * The handling of processor features in X86.td in the X86 backend has been
> completely refactored, removing ProcModel and ProcFeatures in favour of a
> ProcessorFeatures tablegen class.
> [r355872](https://reviews.llvm.org/rL355872).
>
> * A new MsgPackDocument class was added.
> [r356080](https://reviews.llvm.org/rL356080).
>
>
> ## Clang commits
>
> * A script was committed that invokes C-Reduce on an input file to produce a
> minimal reproducer for Clang crashes.
> [r355944](https://reviews.llvm.org/rL355944).
>
> * The clangd fuzzy-matching algorithm was tweaked.
> [r356261](https://reviews.llvm.org/rL356261).
>
>
> ## Other project commits
>
> * LLDB gained the ability to import the std module into the expression parser
> to improve C++ debugging. [r355939](https://reviews.llvm.org/rL355939).
>
> * Deprecation warnings were changed to enabled by default in libcxx.
> [r355961](https://reviews.llvm.org/rL355961).
>
> * LLDB's DWARF parsing code was updated to return llvm::Error and
> llvm:Expected. [r356190](https://reviews.llvm.org/rL356190),
> [r356278](https://reviews.llvm.org/rL356278).
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev