[llvm-dev] LLVM Weekly - #279, May 6th 2019

[Bekket McClane via llvm-dev]

There seems to be a typo in the mailing list section 

> On May 6, 2019, at 11:17 AM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> LLVM Weekly - #279, May 6th 2019
> ================================
> 
> If you prefer, you can read a HTML version of this email at
> <http://llvmweekly.org/issue/279>.
> 
> Welcome to the two hundred and seventy-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
> 
> The next Austin LLVM Social will be [on Thursday 30th
> May](http://lists.llvm.org/pipermail/llvm-dev/2019-May/132098.html).
> 
> A Toronto LLVM/Clang meetup will take place [on Tuesday 14th
> May](http://lists.llvm.org/pipermail/llvm-dev/2019-April/132021.html).
> 
> Jan Hubička has yet another excellent blog post on compiler optimisation, this
> time on [GCC 9's link-time and inter-procedural optimisation
> improvements](http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html).
> 
> GCC 9.1 [has been released](https://lwn.net/Articles/787385/).
> 
> Krister Walfridsson blogged on [how LLVM optimises geometric
> sums](https://kristerw.blogspot.com/2019/04/how-llvm-optimizes-geometric-sums.html).
> 
> 
> ## On the mailing lists
> 
> * Jesper Antonsson shared an
> [RFC](http://lists.llvm.org/pipermail/llvm-dev/2019-May/132080.html) on
> removing the assumption that 1 byte == 8 bits. This generated plenty of
> discussion.
> 
> * Graham Hunter [made an
> update](http://lists.llvm.org/pipermail/llvm-dev/2019-April/132054.html) on
> scalable vector types and SVE upstreaming, including a handy diagram showing
> the dependencies of the different components and expected controversy level.
> 
> * Stephen Kelly [shared EuroLLVM roundtable
> notes](http://lists.llvm.org/pipermail/cfe-dev/2019-May/062217.html) on future
> refactoring with AST-matchers.
> 
> * Todd Snider wrote an
> [RFC](http://lists.llvm.org/pipermail/llvm-dev/2019-April/132041.html) on
> supporting additional symbol metadata in ELF object files as supported by some
> ARM compilers. e.g. `int a __attribute__((location(0x1000))) = 4;`.
> 
> * Andrew Kaylor shares an
> [RFC](http://lists.llvm.org/pipermail/llvm-dev/2019-April/132056.html) on
> extending optimisation reporting. He splits this into two categories, 1) ways
> to support different sorts of output, and 2) ways to create connections
> between different events represented in the report.
> 
> * Serge Guelton is seeking feedback on his effort to [generalise LLVM
> extensions that provide new
> passes](http://lists.llvm.org/pipermail/llvm-dev/2019-May/132128.html),
> allowing projects in tools/ that register themselves with an appropriate CMake
> variable having their passes register in clang/opt/bugpoint.
> 
> * Johannes Doerfert is [seeking
> input](http://lists.llvm.org/pipermail/llvm-dev/2019-May/132082.html) on his
> proposal for the interplan of Clang and Flag and LLVM for OpenMP.
Maybe it’s Clang and Flang?

> 
> * Stephen Scalpone started a thread on [renaming
> f18](http://lists.llvm.org/pipermail/llvm-dev/2019-April/132019.html),
> suggesting 'fortran' as the name. Most respondents prefer using the 'flang'
> name.
> 
> 
> ## LLVM commits
> 
> * The GlobalISel legalizer documentation was updated.
> [r359705](https://reviews.llvm.org/rL359705).
> 
> * More gfx1010 support has been landing in the AMDGPU backend.
> [r359621](https://reviews.llvm.org/rL359621),
> [r359696](https://reviews.llvm.org/rL359696),
> [r359698](https://reviews.llvm.org/rL359698), and more.
> 
> * In preparation for the AArch64 ILP32 support, DAG pointer size can be
> different from the memory representation.
> [r359676](https://reviews.llvm.org/rL359676).
> 
> * FileCheck gained @LINE numeric expressions.
> [r359741](https://reviews.llvm.org/rL359741).
> 
> * The in-tree gn build system gained support for building libunwind, libcxxabi
> and libc++. [r359804](https://reviews.llvm.org/rL359804),
> [r359805](https://reviews.llvm.org/rL359805),
> [r359806](https://reviews.llvm.org/rL359806).
> 
> * RegAllocFast gained a new heuristic to detect values not live-out of a
> block. [r359906](https://reviews.llvm.org/rL359906).
> 
> 
> ## Clang commits
> 
> * Support for the C++2a explicit bool specifier was added.
> [r359949](https://reviews.llvm.org/rL359949).
> 
> * Support for C++2a "familiar template syntax for generic lambdas" was
> committed. [r359967](https://reviews.llvm.org/rL359967).
> 
> 
> ## Other project commits
> 
> * compiler-rt gained a simple crtbegin.o and crtend.o implementation.
> [r359591](https://reviews.llvm.org/rL359591).
> 
> * The LLVM OpenMP library gained OpenMP 5.0 monotonic support.
> [r359601](https://reviews.llvm.org/rL359601).
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev