Alex Bradbury via llvm-dev
2019-Mar-18 19:41 UTC
[llvm-dev] LLVM Weekly - #272, March 18th 2019
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). 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).
Roman Lebedev via llvm-dev
2019-Mar-18 19:47 UTC
[llvm-dev] LLVM Weekly - #272, March 18th 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