[llvm-dev] LLVM Weekly - #103, Dec 21st 2015

[Alex Bradbury via llvm-dev]

LLVM Weekly - #103, Dec 21st 2015
================================

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

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

Regular readers will know about lowRISC, a not-for-profit project a group of
us founded aiming to produce a complete open-source System-on-Chip in volume.
We've just hit a new milestone with the [untethering of the base
SoC](http://www.lowrisc.org/blog/2015/12/untethered-lowrisc-release/). If
you're interested in contributing, the blog post contains a number of
potential starting points.


## News and articles from around the web

The 6th EuroLLVM conference will be held on March 17th-18th in Barcelona,
Spain. The [call for
papers](http://lists.llvm.org/pipermail/llvm-dev/2015-December/093291.html) is
now open and will remain open until January 25th 2016.
EuroLLVM CFP

Chandler Carruth's keynote, "Understanding compiler optimizations" from the
Meeting C++ 2015 conference is [now
online](https://www.youtube.com/watch?v=qkzaZumt_uk).

Richard Pennington has blogged about [bootstrapping LLVM and Clang using
pre-compiled ELLCC binaries](http://ellcc.org/blog/?p=26397).

Bloomberg is going to be holding a [weekend Clang and LLVM
hackathon](http://lists.llvm.org/pipermail/llvm-dev/2015-December/093412.html)
in NYC and in London on February 6th and 7th. The event will be open to
everyone in the community and Bloomberg will provide space, power, food,
beverages, and internet access.They're looking for experienced Clang and
LLVM developers to help as mentors.


## On the mailing lists

* Marshall Clow proposes [dropping support in libc++ for GCC versions prior to
4.7](http://lists.llvm.org/pipermail/cfe-dev/2015-December/046575.html). Eric
Fiselier suggests that actually GCC 4.7 and 4.8 have a rather large number of
test failures and [4.9 would be a more sensible
requirement](http://lists.llvm.org/pipermail/cfe-dev/2015-December/046584.html).

* Dmitry Polukhin has proposed an [RFC on supporting GCC's ifunc
attribute](http://lists.llvm.org/pipermail/llvm-dev/2015-December/093414.html).
He proposes three potential approaches and feedback so far prefers the second.

* Easwaran Raman has posted an RFC on [hotness thresholds in profile-guided
optimisation](http://lists.llvm.org/pipermail/llvm-dev/2015-December/093388.html).
The proposal attempts to define a way of determining hot blocks that works
both for programs with few hot-spots and a long tail of frequently executed
blocks.


## LLVM commits

* LLVM IR now supports floating point atomic loads and stores.
[r255737](http://reviews.llvm.org/rL255737).

* New attributes have been introduced: `InaccessibleMemOnly` (a function may
only access memory that is not accessible by the module being compiled)
and `InaccessibleMemOrArgMemOnly` (a function may only access memory that is
either not accessible by the module being compiled or is pointed to by its
pointer arguments). [r255778](http://reviews.llvm.org/rL255778).

* The PowerPC backend gained support for soft float operations on ppc32.
[r255516](http://reviews.llvm.org/rL255516).

* The `terminatepad` instruction has been removed from LLVM IR.
[r255522](http://reviews.llvm.org/rL255522).

* IR call instructions can now take a fast-math flags marker which indicates
fast-math flags may allow otherwise unsafe optimisations.
[r255555](http://reviews.llvm.org/rL255555).

* LLVM gained a C++11 ThreadPool in its internal library. It is intended to be
used for ThinLTO. [r255593](http://reviews.llvm.org/rL255593).

* The default set of passes has been adjusted. mem2reg will not be run
immediately after globalopt and more scalar optimization passes have been
added to the LTO pipeline. [r255634](http://reviews.llvm.org/rL255634).

* The llvm-profdata tool now supports specifying a weight when merging profile
data. This can be used to give more relative importance to one of multiple
profile runs. [r255659](http://reviews.llvm.org/rL255659).

* For CMake builds, a `compile_commands.json` file will now be generated which
tells tools like YouCompleteMe and `clang_complete` how to build each source
file. [r255789](http://reviews.llvm.org/rL255789).

* The Hexagon VLIW packetizer saw a large update (though unfortunately the
changes aren't summarised in the commit message).
[r255807](http://reviews.llvm.org/rL255807).

* A number of LLVM's C APIs have been depreciated: LLVMParseBitcode,
LLVMParseBitcodeInContext, LLVMGetBitcodeModuleInContext and
LLVMGetBitcodeModule. These have been replaced with new versions of the
functions which don't record a diagnostic.
[r256065](http://reviews.llvm.org/rL256065).

* The AVR backend (which is being imported incrementally) gained AVR.td and
AVRRegisterInfo.td. [r256120](http://reviews.llvm.org/rL256120).


## Clang commits

* A new checker has been introduced to detect excess padding in classes and
structs. [r255545](http://reviews.llvm.org/rL255545).

* A new control-flow integrity mode was introduced, cross-DSO CFI allows
control flow to be protected across shared objects. It is currently marked
experimental. [r255694](http://reviews.llvm.org/rL255694).

* Clang's CMake build system now supports generating profile data for Clang.
[r255740](http://reviews.llvm.org/rL255740),
[r256069](http://reviews.llvm.org/rL256069).


## Other project commits

* It is now possible to suppress reports from UndefinedBehaviourSanitizer for
certain files, functions, or modules at runtime.
[r256018](http://reviews.llvm.org/rL256018).

* The llvm test-suite's CMake+Lit runner gained support for SPEC2000 and SPEC
CPU95. [r255876](http://reviews.llvm.org/rL255876),
[r255878](http://reviews.llvm.org/rL255878).