LLVM Weekly - #74, Jun 1st 2015

LLVM Weekly - #74, Jun 1st 2015

LLVM Weekly - #74, Jun 1st 2015

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

Welcome to the seventy-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@asbradbury.org>, or
@llvmweekly or @asbradbury on Twitter.

You may be interested in the [second RISC-V
which will be held in Berkeley June 29-30. Early bird registration ends today,
but academics can register for free. My colleague Wei and I will be there
representing [lowRISC](http://www.lowrisc.org).

## News and articles from around the web

[MPI-Checker](https://github.com/0ax1/MPI-Checker), a static analysis tool for
MPI code has been released. It is of course implemented using Clang's [Static
Analyzer framework](http://clang-analyzer.llvm.org/).

The LLVM-HPC2 workshop will be held on November 15th, co-located with SC15.
The [call for
papers](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86349) has
been published. Submissions are due by September 1st.

## On the mailing lists

* The discussion about improving LLD has resumed. Rui Ueyama has [written
about his recent patch for a section-based PE/COFF
linker](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86306). Sean
Silva argues that [refactoring might be a better

* Hans Wennborg has shared a [preliminary release plan for LLVM/Clang
3.7](http://article.gmane.org/gmane.comp.compilers.clang.devel/42972). This
would see the codebase branched on the 14th of July with a release target of
the end of August. Tom Stellard has also shared a [schedule for the 3.6.2
release](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86175). The
deadline for patches is June 15 with the release date targeted for June 29th.

* Teresa Johnson has posted an [updated RFC of her ThinLTO implementation
plan](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86282). There
are still concerns about the wrapping of LLVM bitcode in ELF. Alex Rosenberg
suggests [implementing an objcopy replacement for LLVM and extending bitcode
as necessary](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86313)
as an alternative approach.

* Chris Bieneman has posted a [status update on the quest to replace the
autoconf build system with

* Quentin Colombet is [seeking benchmark
reports](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86222) (or
indeed bugs!) for the recently added 'shrink wrapping'.

* Matthias Braun has left a quick note for maintainers of out-of-tree targets
that [pristine register semantics have been modified

* Chandler Carruth has posted some thoughts on [next steps for loop unrolling

## LLVM commits

* Codegen for memcpy on Thumb2 has been improved to make use of load/store
multiple (more details of how this works in the commit message, worth a read
for those interested). [r238473](http://reviews.llvm.org/rL238473).

* Popcount on x86 will now be implemented using a [lookup table in register

* Work continues on reducing peak memory usage through optimisations to debug
info. [r238364](http://reviews.llvm.org/rL238364).

* Initial support for the `convergent` attribute has landed.

* The documentation about the current state of LLVM's Phabricator has been
updated along with a call for volunteers to help develop necessary
improvements and modifications to Phabricator's PHP codebase.

* MCJIT gained support for MIPS64r2 and MIPS64r6.

## Clang commits

* Clang's handling of `-fopenmp` has been rewritten.

* The user documentation on profiling has been extended.

Another Clang commit that should be called out specifically is that
__declspec is no longer treated as a core language extension by Clang,
but instead requires -fms-extensions or -fborland to be passed to
enable support for it. Support for __declspec is also enabled when
compiling CUDA code, but as a stopgap compatibility measure because
some of the CUDA headers are relying on it.