[llvm-dev] LLVM Weekly - #168, Mar 20th 2017

[Alex Bradbury via llvm-dev]

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).