[llvm-dev] LLVM Weekly - #152, Nov 28th 2016

Alex Bradbury via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 28 01:19:01 PST 2016

LLVM Weekly - #152, Nov 28th 2016

If you prefer, you can read a HTML version of this email at

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

I'm back in the Bay Area again this week for a very brief trip, where I'll be
at the RISC-V workshop. I'll be talking about RISC-V LLVM and why we (the
[lowRISC](http://www.lowrisc.org) project see this is an important part of our
efforts to produce a completely open source SoC. Hopefully I'll see some of
you there.

## News and articles from around the web

RV, the [Region Vectorizer framework for LLVM](https://github.com/simoll/rv)
is now [publicly
As described by one of the author, it provides a unified interface to
vectorize code regions.
The authors are hoping to upstream parts of RV.

Botond Ballo has written up a [trip
from the recent C++ standards meeting in Issaquah.

The Transport Trigger Architecture (TTA) Code-design Environment v1.14 [has
This adds support for LLVM 3.9, as well as variable-length local arrays and
alloca amongst other changes.

[mulle-objc](https://mulle-objc.github.io/), a new Objective-C compiler and
runtime has been announced. The compiler is a fork of Clang. The [discussion
of the project on Hacker News](https://news.ycombinator.com/item?id=13042199)
has some more details.

## On the mailing lists

* Discussion has
on the proposed patches for ARM's scalable vector extension (SVE). As Renato
Golin [points
out](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107520.html), the
fact the SVE spec hasn't yet been published makes reviewing the patch somewhat
difficult. Some concerns have been raised that the choice to modify IR rather
than rely on intrinsics may not have been fully justified.

* Malcolm Parsons has proposed [integrating support for constexpr
in order to reduce the number static initializers. A barrier to implementing
this is that lack of a fully portable constexpr strlen. The thread discusses a
number of workarounds.

* Gadi Haber has posted an RFC on [reducing X86 code size by using the VEX
AVX512 encoding where
As [pointed
out](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107446.html) by
Hal Finkel, tablegen's InstrMapping feature makes this easier to implement.

* Sean Silva has done some [more
of the page fault costs of LLD on Linux.

## LLVM commits

* Integer min/max are now canonicalized in InstCombine.

* The interface to TargetMachine::getSymbol has been simplified.

* TargetLibraryInfo gained new functions to determine if integer parameters
should be zeroext or signext. [r287533](http://reviews.llvm.org/rL287533).

* New IntrInaccessibleMemOnly and IntrInaccessibleMemOrArgMemOnly properties
were added for intrinsics. This indicates the intrinsic only accesses memory
that isn't accessible by the module being compiled, or in the case of the
latter property memory accessible via its pointer-typed arguments.

* Analyses now have an AnalysisKey rather than a `static char PassID`.

## Clang commits

* PPC gained various arithmetic builtins for vector arithmetic in altivec.h.

* The OpenCL frontend now differentiates between read and write pipe types,
meaning an error can be raised when passing a read-only pipe to write-only
pipe argument. [r287343](http://reviews.llvm.org/rL287343).

## Other project commits

* LLD's `uncompress()` and `splitIntoPieces()` has been parallelized. This
reduced link time for a debug build of Clang from 8.43s to 6.75s.

* XRay support was added to AArch64 in compiler-rt.

* LLD will now, by default, bail out after printing 20 errors.

More information about the llvm-dev mailing list