Alex Bradbury via llvm-dev
2016-Nov-14 11:22 UTC
[llvm-dev] LLVM Weekly - #150, Nov 14th 2016
LLVM Weekly - #150, Nov 14th 2016
================================
If you prefer, you can read a HTML version of this email at
<http://llvmweekly.org/issue/150>.
Welcome to the one hundred and fiftieth 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 author of the [Cretonne code
generator](https://github.com/stoklund/cretonne) has written a document
[comparing it to
LLVM](http://cretonne.readthedocs.io/en/latest/compare-llvm.html). There has
also been discussion on [using Cretonne as a backend for
Rust](https://internals.rust-lang.org/t/possible-alternative-compiler-backend-cretonne/4275).
You may be interested in the [recently released 'bloaty'
tool](http://blog.reverberate.org/2016/11/07/introducing-bloaty-mcbloatface.html),
a size profiler for binaries.
There will be an LLVM social [today in Salt Lake
City](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107007.html),
which should be convenient for anyone attending SC16.
The next LLVM social in Paris [will take place on November
22nd](http://lists.llvm.org/pipermail/llvm-dev/2016-November/106953.html).
Note registration is required.
## On the mailing lists
* Renato Golin has now shared the [final results for the survey on moving LLVM
development to
GitHub](http://lists.llvm.org/pipermail/llvm-dev/2016-November/106941.html).
As Chris Lattner
[comments](http://lists.llvm.org/pipermail/llvm-dev/2016-November/106989.html),
there is clear support for moving to GitHub in some way although the multirepo
vs monorepo debate is far from over.
* Chris Bieneman has posted an RFC on creating a new [ClangDebuggerSupport
library](http://lists.llvm.org/pipermail/cfe-dev/2016-November/051469.html).
This would allow code currently in LLDB which relies on internal Clang details
to be maintained alongside the Clang source. "The long-term goal of this
library is to provide the implementation for what could some day become a
defined `debugger<->frontend` interface for providing modularized (maybe
even
plugin-based) language debugging support in LLDB."
* Serge Pavlov has updated his [proposal on adding configuration file support
to Clang](http://lists.llvm.org/pipermail/cfe-dev/2016-November/051458.html).
* Bob Haarman is interested in [rewriting the recently added opt-viewer tool
in C++](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107039.html) to
overcome performance issues found when using the current Python implementation
on large codebases.
* Igor Laevsky proposes [adding 'atomic' versions of
llvm.{memcpy,memmove,memset}
intrinsics](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107018.html).
These would better match the semantics of languages like Java. As was pointed
out, calling these versions 'atomic' is perhaps misleading, as it is
only the
per-element accesses that are atomic.
* Jack Andersen has shared an RFC on [target-independent small data section
handling](http://lists.llvm.org/pipermail/llvm-dev/2016-November/106889.html).
* Sanjay Patel
[wonders](http://lists.llvm.org/pipermail/llvm-dev/2016-November/106868.html)
if LLVM might benefit from IR intrinsics for integer min/max. A key motivation
is that there are multiple ways of specifying it in IR and it's not clear
which is canonical. Having a canonical form makes it easier for the relevant
optimisation passes. There hasn't been much support for adding a new
intrinsic
in the responses so far.
* Chris Lattner has
[clarified](http://lists.llvm.org/pipermail/llvm-dev/2016-November/107023.html)
that the intent for the Apache 2 attribution exception that LLVM ends up with
is to allow LLVM runtimes to be used without attribution.
## LLVM commits
* The previously proposed type-safe general purpose formatting library has
been added in the form of the `llvm::formatv` function.
[r286682](http://reviews.llvm.org/rL286682).
* Initial documentation for XRay in LLVM has been committed.
[r286319](http://reviews.llvm.org/rL286319).
* getelementptr indices can now carry an `inrange` attribute.
[r286514](http://reviews.llvm.org/rL286514).
* Scripts to aid working with a git monorepo have been committed to the LLVM
tree. Currently only 'push' from the monorepo is supported. Support has
also
been added to the CMake build system for monorepo-like directory layout (at
this point, still unofficial).
[r286138](http://reviews.llvm.org/rL286138),
[r286162](http://reviews.llvm.org/rL286162).
* SystemZ's tablegen instruction definitions have undergone some
refactoring.
[r286263](http://reviews.llvm.org/rL286263),
[r286268](http://reviews.llvm.org/rL286268).
* Support was dropped for 'old style' scalar type-based alias analysis
tags,
though the textual and bitcode 'upgrade' code is still present.
[r286291](http://reviews.llvm.org/rL286291).
* A new formatter was added to help pretty printing hex bytes into a
`raw_ostream`. [r286316](http://reviews.llvm.org/rL286316).
* Operand bundles are no longer considered 'experimental'.
[r286428](http://reviews.llvm.org/rL286428).
* LLVM gained an initial `llvm-strings` tool, as a replacement to the binutils
strings. It is not yet feature complete. It feels like contributing towards
feature parity with binutils strings might be a good starter project for
someone wanting to contribute to LLVM.
[r286556](http://reviews.llvm.org/rL286556).
* Basic plumbing has been added for GlobalISel with the ARM backend - enough
to select a `ret void`. [r286573](http://reviews.llvm.org/rL286573).
* ORC RPC utilities have seen a refactoring and some new features, which are
described in the commit message. [r286620](http://reviews.llvm.org/rL286620).
* The AMDGPU backend now supports half-precision floats.
[r286753](http://reviews.llvm.org/rL286753).
## Clang commits
* The output of `-ast-print` is now valid C++ code, instead of _almost_ valid
C++ code. [r286439](http://reviews.llvm.org/rL286439).
* A new optimisation option, `-Og` was added. In the future, this may disable
certain optimisation in order to improve debuggability.
[r286602](http://reviews.llvm.org/rL286602).
## Other project commits
* LLD now supports the `--symbol-ordering-file` argument. The linker will use
the passed symbols file to sort sections in output, which can help to reduce
startup time. [r286440](http://reviews.llvm.org/rL286440).
* LLD has started to insert its version information in the .comment section of
its output. [r286496](http://reviews.llvm.org/rL286496).
* ThreadSanitizer can now be used to check OpenMP programs.
[r286115](http://reviews.llvm.org/rL286115).