Alex Bradbury via llvm-dev
2018-Sep-10 19:09 UTC
[llvm-dev] LLVM Weekly - #245, September 10th 2018
LLVM Weekly - #245, September 10th 2018 ==================================== If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/245>. Welcome to the two hundred and forty-fifth 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 Applications for LLVM Foundation Travel Grants for full time undergraduate and graduate students are [open until September 12th](http://lists.llvm.org/pipermail/llvm-dev/2018-September/125872.html). The next Zurich LLVM Compiler Social will be [held on Thursday 13th September](http://lists.llvm.org/pipermail/llvm-dev/2018-September/125858.html). It features talks on the Lean and Isabelle theorem provers. The 4th LLVM/GCC social in Shenzhen will [take place on September 16th](http://lists.llvm.org/pipermail/llvm-dev/2018-September/125933.html). Bekket McClane's series on writing an LLVM pass continues with guidance on [integrating the pass into Clang](https://medium.com/@mshockwave/writing-llvm-pass-in-2018-part-iv-d69dac57171d). Nuno Lopes and John Regehr have published a fascinating paper [Future Directions for Optimizing Compilers](https://arxiv.org/pdf/1809.02161.pdf) on arXiv. "This paper examines the problem of making optimizing compilers faster, less buggy, and more capable of generating high-quality output." ## On the mailing lists * Paul Kirth has shared an RFC on [upstreaming Syringe, a dynamic behaviour injection framework](http://lists.llvm.org/pipermail/cfe-dev/2018-September/059260.html). Developed as part of a Google internship, this framework allows users to specify alternate implementations of functions and dynamically switch behaviour at runtime. Gábor Márton provided [feedback](http://lists.llvm.org/pipermail/cfe-dev/2018-September/059269.html) based on his work on `fci_mock` which was presented at EuroLLVM this year and suggests joining forces. David Chisnall [suggests](http://lists.llvm.org/pipermail/cfe-dev/2018-September/059282.html) looking at the LOOM framework which provides similar functionality. * Jakub Kuderski has posted an RFC on [per-callsite inline intrinsics](http://lists.llvm.org/pipermail/cfe-dev/2018-September/059232.html), making it possible to manually force desired inlining decisions with a fine granularity. * Jonas Paulsson kicked off a discussion on [improving sequences of shufflevector instructions produced by the loop vectorizer](http://lists.llvm.org/pipermail/llvm-dev/2018-September/125826.html). * The 7.0.0 release is [almost ready](http://lists.llvm.org/pipermail/llvm-dev/2018-September/125850.html), but there will be a final release candidate (rc3) before the final tag. Hans Wennborg is requesting further additions to the release notes. * Kristina Brooks [proposes](http://lists.llvm.org/pipermail/cfe-dev/2018-September/059222.html) a new `__builtin_type_name` Clang extension to retrieve a type name from a pointer. Full justification is given in the thread, which generated a reasonable amount of discussion. ## LLVM commits * A new "hot cold" splitting pass was introduced, which can use profile information to outline cold regions to a separate function. [r341669](https://reviews.llvm.org/rL341669). * A new control height reduction pass was merged. This uses information from profiling to merge conditional blocks of code, merging the number of conditional branches in the hot path. [r341386](https://reviews.llvm.org/rL341386). * There were a number of changes related to the SpeculativeLoadHardening 'Spectre' mitigation pass. It learned to harden indirect branches and switches without retpolines, gained a mitigation against the ret2spec attack, and an LLVM IR attribute was added indicating a function body has speculative load hardening enabled. [r341356](https://reviews.llvm.org/rL341356), [r341358](https://reviews.llvm.org/rL341358), [r341363](https://reviews.llvm.org/rL341363). * `TargetInstrInfo::has{StoreTo,LoadFrom}StackSlot` was extended to return an array of accesses. [r341301](https://reviews.llvm.org/rL341301). * `-Rpass-analysis=size-info` will now output per-function size-info remarks rather than per-module summaries. [r341588](https://reviews.llvm.org/rL341588). * llvm-objcopy gained support for compressing DWARF .debug sections. [r341635](https://reviews.llvm.org/rL341635). * MemorySanitizer was extended with KMSAN, for kernel instrumentation. [r341637](https://reviews.llvm.org/rL341637). ## Clang commits * A new compact binary serialization format was defined for clangd's symbol index. This is 10x more compact than YAML and 40% more compact than gzipped AML. [r341375](https://reviews.llvm.org/rL341375). * DWARF accelerator tables are now enabled by default when tuning for LLDB. [r341564](https://reviews.llvm.org/rL341564). * The deprecated getLocStart, getBeginLoc and getLocEnd APIs were removed. [r341573](https://reviews.llvm.org/rL341573). ## Other project commits * LLVM's OpenMP library gained an initial implementation of the OMP 5.0 memory management routines. [r341687](https://reviews.llvm.org/rL341687). * libFuzzer tests were enabled on Windows. [r341385](https://reviews.llvm.org/rL341385).