Alex Bradbury via llvm-dev
2017-Mar-20 12:46 UTC
[llvm-dev] LLVM Weekly - #168, Mar 20th 2017
LLVM Weekly - #168, Mar 20th 2017 ================================ If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/168>. Welcome to the one hundred and sixty-eighth 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](http://asbradbury.org). 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 big news this week is obviously that LLVM+Clang+... 4.0.0 [was released](http://lists.llvm.org/pipermail/llvm-dev/2017-March/111025.html). Congratulations everyone! An LLVM social in Milan [will take place](http://lists.llvm.org/pipermail/llvm-dev/2017-March/111187.html) on April 21st. Please register if you are planning to attend. LLVM Socials in Sweden have [now set up](http://lists.llvm.org/pipermail/llvm-dev/2017-March/111242.html) a [meetup page](https://www.meetup.com/LLVM-Clang-Sweden-socials/). Do join the group if you're interested in joining future socials in Sweden. Version 1.15 of the TTA-based Co-design Environment (TCE) has been released, supporting LLVM 4.0.0. ## On the mailing lists * Rui Ueyama suggests that LLD is now at the point where it should be "production ready" on x86-64. Please [help out](http://lists.llvm.org/pipermail/llvm-dev/2017-March/111083.html) by trying it on your favourite project and reporting any issues. A common issue is that libtool doesn't yet recognise LLD as a GNU-compatible linker. * Renato Golin [proposes](http://lists.llvm.org/pipermail/llvm-dev/2017-March/111129.html) turning `-ffp-contract=fast` on by default. This would match GCC's default behaviour for contracting floating point expressions. Some respondents suggest defaulting to this for C++ but maintaining the status quo for C. * David Menendez [reports](http://lists.llvm.org/pipermail/llvm-dev/2017-March/111000.html) on work from a reimplementation of Alive, specifically the ability to detect when preconditions for LLVM peephole optimisations can be weakened (made more general). * Evgeny Astigeevich [suggests](http://lists.llvm.org/pipermail/llvm-dev/2017-March/111066.html) changing TargetTransformInfo::getGEPCost to take GetElementPtrInst as a parameter, making it possible to provide a more accurate cost estimate. * Ashutosh Nema has [summarised](http://lists.llvm.org/pipermail/llvm-dev/2017-March/111056.html) the two main approaches to implementing epilog loop vectorisation. The thread was very active this week, with lots of discussion following this post. * Matthew Arsenault suggests [allowing backends to have alloca return pointers to a non-zero address space](http://lists.llvm.org/pipermail/llvm-dev/2017-March/111199.html). Some backends need this flexibility, as address space zero has some fixed properties. * Mikhail Zolotukhin reports [results from profiling indicating expensive InstCombine transformations](http://lists.llvm.org/pipermail/llvm-dev/2017-March/111257.html), and suggests disabling some of these at lower optimisation levels. ## LLVM commits * The MachineOutliner gained support for tail calls. [r297653](http://reviews.llvm.org/rL297563). In fact, it looks like I missed when the commit where the MachineOutliner landed (the first attempt was reverted and I missed the retry - sorry!). The outliner reduces code size by finding repeated sequences of instructions and replacing them with function calls. It now supports AArch64 as well as X86. [r297081](http://reviews.llvm.org/rL297081), [r298162](http://reviews.llvm.org/rL298162). * The patch to "simplify consecutive merge store candidate search" seems to have finally landed. Versions of this patch have been committed and subsequently reverted multiple times since last September (and its review history goes back much, much further). This has obviously been a fiddly patch, so we certainly owe our gratitude to the patch authors who have kept with it over such a long period. [r297695](http://reviews.llvm.org/rL297695). * All [failures](https://bugs.llvm.org/show_bug.cgi?id=30999) exposed by `LLVM_ENABLE_EXPENSIVE_CHECKS` have now been resolved, and a new buildbot has been introduced to try to keep things that way. * llvm-pdbdump started to gain support for PDB diffing. [r297689](http://reviews.llvm.org/rL297689). * A new 'ABS' ISD node has been introduced, to produce the absolute value of a signed integer. [r297780](http://reviews.llvm.org/rL297780). * A GDB pretty-printer was committed for the llvm::Twine type. [r297889](http://reviews.llvm.org/rL297889). * Huge stack frames on X86 are now allocated using a short instruction sequence rather than a huge number of small adjustments. I'm curious about the programs allocating multi-gigabyte stack frames... [r298116](http://reviews.llvm.org/rL298116). ## Clang commits * A new warning `-Wbitfield-enum-conversions` was added which warns when assigning an enum to a bitfield that is too small. [r297761](http://reviews.llvm.org/rL297761). * The include fixer gained a 'fuzzy' SymbolIndex, which can be used for global autocomplete. [r297630](http://reviews.llvm.org/rL297630). ## Other project commits * LLDB's file completion now works properly on Windows. [r297585](http://reviews.llvm.org/rL297585). * LLD will helpfully error out early if the output path is invalid. [r297645](http://reviews.llvm.org/rL297645).