[LLVMdev] LLVM Weekly - #64, Mar 23rd 2015

Alex Bradbury asb at asbradbury.org
Mon Mar 23 08:01:44 PDT 2015

LLVM Weekly - #64, Mar 23rd 2015

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

Welcome to the sixty-fourth 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

Students have until Friday 27th March to get their applications in for Google
Summer of Code. This gives the opportunity to get paid $5500 to work on open
source over the summer, under the mentorship of someone from the community.
for the list of mentoring organisations advertising LLVM-related projects.
Please do help spread the word. I am biased, but I'd like to draw particular
attention to the wide variety of [lowRISC GSoC
ideas](http://www.lowrisc.org/docs/gsoc-2015-ideas/), including a project to
implement an LLVM pass using tagged memory to provide protection against
control-flow hijacking.

GCC 5 is starting to [get near to
release](https://gcc.gnu.org/ml/gcc/2015-03/msg00241.html). The first release
candidate is expected in the first week of April.

## On the mailing lists

* Peter Collingbourne has kicked off a thread on [controlling the LTO
level](http://article.gmane.org/gmane.comp.compilers.clang.devel/41832). Using
LTO can cause a massive increase in compile-time. Peter argues that for some
features, like the recently added control flow integrity checks in Clang, you
require LTO for whole program visibility but perhaps would rather do much
fewer optimisations in order to get a more reasonable compile time. He
proposes a `-flto-level` command line option.

* Eric Christopher has [written to the mailing
list](http://article.gmane.org/gmane.comp.compilers.llvm.devel/83858) about
recent changes he's made to the TargetMachine::getSubtarget API.

* Dario Domizioli proposes [adding target-specific defaults for options in the
LLVM tools](http://article.gmane.org/gmane.comp.compilers.llvm.devel/83665).
Response was mostly negative on the grounds that opt, llc, and friends are
tools meant for LLVM developers rather than end-users. Sean Silva attempted to
[clarify the difference between LLVM users, LLVM end-users, and LLVM

## LLVM commits

* The backend for the Hexagon DSP has continued to grow over the past few
weeks. Most recently, support for vector instructions has been added.

* The LLVM developer documentation grew guidance on writing commit messages.

* LLVM learnt to support the ARMv6k target. The commit message has a handy
ascii art diagram to explain its position in the ARM family.

## Clang commits

* The size of a Release+Asserts clang binary has been reduced by ~400k by
devirtualising Attr and its subclasses.

* Work on MS ABI continues, with support for HandlerMap entries for C++ catch.

* A new warning, `-Wpartial-ability` will warn when using decls that are not
available on all deployment targets.

* C++14 sized deallocation has been disabled default due to compatibility
issues. [r232788](http://reviews.llvm.org/rL232788).

## Other project commits

* Performance of a self-hosted lld link has again been improved. It's now down
to 3 seconds on the patch author's machine (vs 5 seconds before, and 8 seconds
for the GNU BFD linker). [r232460](http://reviews.llvm.org/rL232460).

* libcxx gained the `<experimental/tuple>` header which implements most of the
tuple functionality specified in the library fundamentals TS.

* LLD now supports the semantics of simple sections mappings in linker scripts
and can handle symbols defined in them.

* Mips64 lldb gained an initial assembly profiler.

More information about the llvm-dev mailing list