[llvm-dev] LLVM Weekly - #106, Jan 11th 2016

[Alex Bradbury via llvm-dev]

LLVM Weekly - #106, Jan 11th 2016
=================================

If you prefer, you can read a HTML version of this email at
<http://llvmweekly.org/issue/106>.

Welcome to the one hundred and sixth 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.

Many readers may be interested that last week was the 3rd RISC-V Workshop. You
can find slides from the two [lowRISC](http://www.lowrisc.org) talks
[here](https://speakerdeck.com/asb/lowrisc-plans-for-risc-v-in-2016) and
[here](http://riscv.org/workshop-jan2016/Wed1115%20untether_wsong83.pdf). You
may also want to read my
[liveblog of the
event](http://www.lowrisc.org/blog/2016/01/third-risc-v-workshop-day-one/).


## News and articles from around the web

The BSD Now podcast recently [interviewed Alex
Rosenberg](http://www.jupiterbroadcasting.com/92191/the-bsd-black-box-bsd-now-122/)
about his work on LLVM/Clang and FreeBSD.

The folks at QuarksLab have shared a [Clang hardening cheat
sheet](http://blog.quarkslab.com/clang-hardening-cheat-sheet.html).

LLDB 3.8 will [feature initial Go debugging
support](https://groups.google.com/forum/m/#!topic/golang-nuts/pzpNcarQcvo).

The next Paris LLVM Social will be held [on January
27th](http://lists.llvm.org/pipermail/llvm-dev/2016-January/093610.html) and
includes a talk from John Regehr.

The next Zurich LLVM Social [will be taking place on January
14th](http://lists.llvm.org/pipermail/llvm-dev/2015-December/093589.html).


## On the mailing lists

* One long discussion on the lists this week was regarding the design of the
new LLD ELF and COFF linkers. Rui Ueyama [notes that they are currently
designed as commands instead of
libraries](http://lists.llvm.org/pipermail/llvm-dev/2016-January/093712.html).
e.g. exit() on failure is considered appropriate. Chandler Carruth argues
strongly that [supporting a library interface is important for any project
under the LLVM
umbrella](http://lists.llvm.org/pipermail/llvm-dev/2016-January/093760.html).
There ultimately seems to be agreement that the ability to use the linker as a
library is important for some use cases, but also that the person doing the
work (Rui) should be able to go about development in the way that makes most
sense to him. He intends to focus first on reaching feature parity with the
GNU linker, and then look at issues such as the library interface.

* There's been some discussion in the thread on the new global instruction
selection implementation about the [semantics of inttoptr and
ptrtoint](http://lists.llvm.org/pipermail/llvm-dev/2016-January/093739.html).
Specifically whether the currently specified semantics are appropriate for
architectures where converting between integers and pointers is not a no-op.
It looks like [Philip Reames, David Chisnall, and
others](http://lists.llvm.org/pipermail/llvm-dev/2016-January/093802.html)
should share an RFC on this issue in the following weeks.

* Matthew Arsenault asks about [TargetTransformInfo
getOperationCost](http://lists.llvm.org/pipermail/llvm-dev/2016-January/093662.html).
Hal Finkel [points
out](http://lists.llvm.org/pipermail/llvm-dev/2016-January/093670.html) the
problems Matt is seeing are likely down to there being two cost models. One
used for vectorization, and one used for inlining and unrolling.

* James Byerly has an [interesting question about constraint solving and
unspillable register
classes](http://lists.llvm.org/pipermail/llvm-dev/2016-January/093692.html).
He is targetting a custom, seemingly micro-coded architecture and hasn't
received any responses so far.

* Steve King has shared some thoughts on [adding ISD::OPAQUE to complement
ISD::BITCAST](http://lists.llvm.org/pipermail/llvm-dev/2016-January/093626.html).

* What is the current status of LLDB on Windows? Zachary Turner has [written a
summary](http://lists.llvm.org/pipermail/lldb-dev/2016-January/009248.html).

* Both
[Xilinx](http://lists.llvm.org/pipermail/llvm-dev/2016-January/093706.html)
and [Microsoft Research
Cambridge](http://lists.llvm.org/pipermail/llvm-dev/2016-January/093684.html)
are advertising intern positions on LLVM-related projects.


## LLVM commits

* LLVM gained the `-print-funcs` option which can be used to filter IR
printing to only certain functions.
[r256952](http://reviews.llvm.org/rL256952).

* The LLVM ADT library gained a new sum type abstraction for pointer-like
types and an abstraction for embedding an integer within a pointer-like type.
[r257282](http://reviews.llvm.org/rL257282),
[r257284](http://reviews.llvm.org/rL257284).

* LLVM now recognises the Samsung Exynos M1 core.
[r256828](http://reviews.llvm.org/rL256828).

* InstCombine learned to expose more constants when comparing getelementptrs
(GEPs) by detecting when both GEPs could be expressed as GEPs with the same
base pointer. [r257064](http://reviews.llvm.org/rL257064).

* SelectionDAGBuilder will set NoUnsignedWrap for an inbounds getelementptr
and for load/store offsets. [r256890](http://reviews.llvm.org/rL256890).

* AArch64 MachineCombine will now allow fadd and fmul instructions to be
reassociated. [r257024](http://reviews.llvm.org/rL257024).

* Macro emission in DWARFv4 is now supported.
[r257060](http://reviews.llvm.org/rL257060).

* llvm-symbolizer gained the `-print-source-context-lines` option to print
source code around the line. [r257326](http://reviews.llvm.org/rL257326).


## Clang commits

* Clang's CMake build system can now perform a multi-stage bootstrap build
with profile-guided optimisation. [r256873](http://reviews.llvm.org/rL256873).

* Clang's command line frontend learned to handle a whole bunch of
`-fno-builtin-*` arguments. [r256937](http://reviews.llvm.org/rL256937).

* The new ELF LLD linker will now be used for th AMDGPU target.
[r257175](http://reviews.llvm.org/rL257175).


## Other project commits

* The performance of string table construction in the LLD ELF linker has been
improved. This improves link time of lld by 12% from 3.50 seconds to 3.08
seconds. [r257017](http://reviews.llvm.org/rL257017).

* The LLD ELF linker gained support for the AMDGPU target.
[r257023](http://reviews.llvm.org/rL257023).