Alex Bradbury via llvm-dev
2020-Jan-06 19:47 UTC
[llvm-dev] LLVM Weekly - #314, Jan 6th 2020
LLVM Weekly - #314, Jan 6th 2020 =============================== If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/314>. Welcome to the three hundred and fourteenth 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. The very [first LLVM Weekly issue](http://llvmweekly.org/issue/1) went out six years ago today, on Jan 6th 2014. Since then there's been a new issue every single Monday, with zero gaps. Thank you everyone for reading so far! I of course intend to keep it going through 2020 as well. ## News and articles from around the web The deadline for proposals for EuroLLVM 2020 [is this Saturday 11th January](http://lists.llvm.org/pipermail/llvm-dev/2020-January/137881.html). EuroLLVM will take place April 6th-7th in Paris. The program for the LLVM dev room at FOSDEM 2020 [has been published](https://fosdem.org/2020/schedule/track/llvm/). Corentin Jabot wrote up a detailed blog post on [improving performance for large integer arrays in Clang](https://cor3ntin.github.io/posts/arrays/). The second LLVM social in Bangalore [will take place](http://lists.llvm.org/pipermail/llvm-dev/2020-January/137938.html) on Saturday February 1st. ## On the mailing lists * Mark de Wever kicked off an RFC thread on [handling implementation limits in Clang](http://lists.llvm.org/pipermail/cfe-dev/2020-January/064177.html), suggesting that implementation limits of the Clang compiler be centralised to allow them to be representated in generated headers and documentation. * Michael Kruse [proposes a new loop optimisation framework](http://lists.llvm.org/pipermail/llvm-dev/2020-January/137909.html). "The central idea is to use a modifiable loop tree - similar to LoopInfo - as the primary representation. LLVM-IR is converted to a loop tree, then optimized and finally LLVM-IR is generated again for subtrees that are considered profitable." * David Blaikie posted an RFC on [reducing .o file size in DWARFv5](http://lists.llvm.org/pipermail/llvm-dev/2019-December/137863.html), Using `DW_AT_ranges` can resuled in significant size savings for for .o, but can cause a very small increase for .dwo files. * Whitney T Tsang proposes [changing LoopUnrollAndJamPass from a loop to a function pass](http://lists.llvm.org/pipermail/llvm-dev/2020-January/137901.html). ## LLVM commits * The pass registration mechanism used by Polly was generalised so it can be used by any third party tool. [24ab9b5](https://reviews.llvm.org/rG24ab9b537e6). * The check for the `disable-tail-calls` attribute was hoisted from individual backends to the instruction selectors. [9c2b728](https://reviews.llvm.org/rG9c2b72821be). * The NoFPExcept SDNodeFlag now defaults to false. [6333679](https://reviews.llvm.org/rG63336795f0d). * Zlib support is now disabled by default on Windows. [a2ca1c2](https://reviews.llvm.org/rGa2ca1c2d566). ## Clang commits * OpenMP 5.0 implementation continues with support for codegen of lastprivate conditional list items. [a58da1a](https://reviews.llvm.org/rGa58da1a2ff0). * clang-tidy gained a utility function to add 'const' to variables. [cf48101](https://reviews.llvm.org/rGcf48101200e). ## Other project commits * MLIR gained documentation for the VectorOps dialect. [a932f03](https://reviews.llvm.org/rGa932f033a34). * LLD gained support for TPREL relocations for Hexagon. [81ffe89](https://reviews.llvm.org/rG81ffe89735e).
Philip Reames via llvm-dev
2020-Jan-06 19:50 UTC
[llvm-dev] LLVM Weekly - #314, Jan 6th 2020
Six years? Wow! Alex, thank you for your work here. The service you provide to the community is one I really appreciate and have come to rely on. Thank you! Philip On 1/6/20 11:47 AM, Alex Bradbury via llvm-dev wrote:> LLVM Weekly - #314, Jan 6th 2020 > ===============================> > If you prefer, you can read a HTML version of this email at > <http://llvmweekly.org/issue/314>. > > Welcome to the three hundred and fourteenth 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. > > The very [first LLVM Weekly issue](http://llvmweekly.org/issue/1) went out six > years ago today, on Jan 6th 2014. Since then there's been a new issue every > single Monday, with zero gaps. Thank you everyone for reading so far! I of > course intend to keep it going through 2020 as well. > > > ## News and articles from around the web > > The deadline for proposals for EuroLLVM 2020 [is this Saturday 11th > January](http://lists.llvm.org/pipermail/llvm-dev/2020-January/137881.html). > EuroLLVM will take place April 6th-7th in Paris. > > The program for the LLVM dev room at FOSDEM 2020 [has been > published](https://fosdem.org/2020/schedule/track/llvm/). > > Corentin Jabot wrote up a detailed blog post on [improving performance for > large integer arrays in Clang](https://cor3ntin.github.io/posts/arrays/). > > The second LLVM social in Bangalore [will take > place](http://lists.llvm.org/pipermail/llvm-dev/2020-January/137938.html) on > Saturday February 1st. > > > ## On the mailing lists > > * Mark de Wever kicked off an RFC thread on [handling implementation limits in > Clang](http://lists.llvm.org/pipermail/cfe-dev/2020-January/064177.html), > suggesting that implementation limits of the Clang compiler be centralised to > allow them to be representated in generated headers and documentation. > > * Michael Kruse [proposes a new loop optimisation > framework](http://lists.llvm.org/pipermail/llvm-dev/2020-January/137909.html). > "The central idea is to use a modifiable loop tree - similar to LoopInfo - as > the primary representation. LLVM-IR is converted to a loop tree, then > optimized and finally LLVM-IR is generated again for subtrees that are > considered profitable." > > * David Blaikie posted an RFC on [reducing .o file size in > DWARFv5](http://lists.llvm.org/pipermail/llvm-dev/2019-December/137863.html), > Using `DW_AT_ranges` can resuled in significant size savings for for .o, but > can cause a very small increase for .dwo files. > > * Whitney T Tsang proposes [changing LoopUnrollAndJamPass from a loop to a > function > pass](http://lists.llvm.org/pipermail/llvm-dev/2020-January/137901.html). > > > ## LLVM commits > > * The pass registration mechanism used by Polly was generalised so it can be > used by any third party tool. > [24ab9b5](https://reviews.llvm.org/rG24ab9b537e6). > > * The check for the `disable-tail-calls` attribute was hoisted from individual > backends to the instruction selectors. > [9c2b728](https://reviews.llvm.org/rG9c2b72821be). > > * The NoFPExcept SDNodeFlag now defaults to false. > [6333679](https://reviews.llvm.org/rG63336795f0d). > > * Zlib support is now disabled by default on Windows. > [a2ca1c2](https://reviews.llvm.org/rGa2ca1c2d566). > > > ## Clang commits > > * OpenMP 5.0 implementation continues with support for codegen of lastprivate > conditional list items. [a58da1a](https://reviews.llvm.org/rGa58da1a2ff0). > > * clang-tidy gained a utility function to add 'const' to variables. > [cf48101](https://reviews.llvm.org/rGcf48101200e). > > > ## Other project commits > > * MLIR gained documentation for the VectorOps dialect. > [a932f03](https://reviews.llvm.org/rGa932f033a34). > > * LLD gained support for TPREL relocations for Hexagon. > [81ffe89](https://reviews.llvm.org/rG81ffe89735e). > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev