[LLVMdev] LLVM Weekly - #23, Jun 9th 2014

Mon Jun 9 04:21:11 PDT 2014

LLVM Weekly - #23, Jun 9th 2014
===============================

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

Welcome to the twenty-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.

## News and articles from around the web

Philip Reames has [announced that code for late safepoint placement is now
available](http://www.philipreames.com/Blog/2014/06/04/code-for-late-safepoint-placement-available/).
This is a set of patches to LLVM from Azul Systems that aim to support precise
relocating garbage collection in LLVM. Phlip has a long list of questions
where he is seeking feedback from the community on how to move forwards with
these patches. There's not been much response so far, hopefully it will come
soon as I know there are many communities who are very interested in seeing
better GC support in LLVM (e.g. Rust, Ocaml).

The biggest LLVM news this week is of course the announcement of [the Swift
programming language](https://developer.apple.com/swift/) from Apple. Its
development was led by Chris Lattner, original author of LLVM. He has some
more info about Swift [one his website](https://developer.apple.com/swift/).
There is no source release as of yet, and [no
indication](http://article.gmane.org/gmane.comp.compilers.clang.user/493) from
Apple as to whether it will remain proprietary. Either way, it's an
interesting development. Chris Lattner is now on Twitter and has been
[passing out tidbits about the Swift
implementation](https://twitter.com/clattner_llvm/status/474411823223959552).

LunarG have [announced the Glassy Mesa
project](http://lunarg.com/glassymesa/). This project, funded by Valve, will
explore increasing game performance in Mesa through improvements in the shader
compiler. The current parser and optimisation layer are replaced with glslang
and the LLVM-based LunarGlass. More technical details are [available in the
slide
deck](http://media.lunarg.com/wp-content/uploads/2014/06/GlassyMesaSlides-05Jun2014.pdf).

Sébastien Métrot has released [xspray](https://github.com/meeloo/xspray), a
frontend for lldb on OS X. One of its interesting features is the inbuilt
support for plotting your data.

With all the LLVM news recently, it seems [search traffic for 'llvm' has
skyrocketed](http://www.google.com/trends/explore#q=llvm).

## On the mailing lists

* Zachary Tuner has started a discussion on [multi-threading and mutexes in
LLVM](http://article.gmane.org/gmane.comp.compilers.llvm.devel/73604),
following from his patches (currently in review) that tries to replace LLVM's
own mutex implementation with `std::mutex` and `std::recursive_mutex`. The key
questions are whether multi-threading should be a compile-time or tunetime
parameter, what should happen if you attempt to acquire a mutex in an app with
threading disabled, and whether debugging code for finding deadlocks should be
included.

* Sean Silva queries [whether stack maps should be marked as stable in LLVM
3.5](http://article.gmane.org/gmane.comp.compilers.llvm.devel/73597) given
that the feature now has a number of users, including WebKit. Andrew Trick
[suggests another round of
RFC](http://article.gmane.org/gmane.comp.compilers.llvm.devel/73599) before
this, and intends to submit another proposal in the coming week.

* Gerolf Hoflehner is [asking for feedback on his proposed instruction
combiner
pass](http://article.gmane.org/gmane.comp.compilers.llvm.devel/73502). This
would run at the machine IR level and aims to overcome some of the
deficiencies observed when combining instructions at the ISEL level.

* A question has arisen over [whether LLVM 3.3/3.4 IR is backward compatible
with 3.2](http://article.gmane.org/gmane.comp.compilers.llvm.devel/73465).
This isn't a form of compatibility that LLVM offers, though Stephen Hines
notes that [Android maintains an LLVM 3.2 bitcode
writer](http://article.gmane.org/gmane.comp.compilers.llvm.devel/73563).

* Quite some time ago, Dennis Luehring drew attention to [a case where the GCC
optimiser seems to do better than
Clang](http://article.gmane.org/gmane.comp.compilers.clang.devel/31855).
Benjamin Kramer and Richard Smith both submitted patches which [now results in
Clang acing this
testcase](http://article.gmane.org/gmane.comp.compilers.clang.devel/37067).

## LLVM commits

* The jumptable attribute has been introduced. If you mark a function with
this attribute, references to it can be rewritten with a reference to the
appropriate jump-instruction-table function pointer.
[r210280](http://reviews.llvm.org/rL210280).

* Support was added for Windows ARM exception handling data structures,
including decoding them.
[r209998](http://reviews.llvm.org/rL209998),
[r210192](http://reviews.llvm.org/rL210192).

* GlobalAlias can now point to an arbitrary ConstantExpression. See the commit
message for a discussion of the consequences of this.
[r210062](http://reviews.llvm.org/rL210062).

* The subword level parallelism (SLP) vectorizer has been extended to support
vectorization of getelementptr expressions.
[r210342](http://reviews.llvm.org/rL210342).

* The LLVM programmer's manual has been improved with an example of using
IRBuilder. [r210354](http://reviews.llvm.org/rL210354).

## Clang commits

* Semantic analysis to make sure a loop is in OpenMP canonical form has been
committed. [r210095](http://reviews.llvm.org/rL210095).

* `__builtin_operator_new` and `__builtin_operator_delete` have been added.
Some optimisations are allowed on these which would not be on `::operator new`
and are intended for the implementation of things like std::allocator.
[r210137](http://reviews.llvm.org/rL210137).

* New pragmas have been introduced to give optimisation hints for
vectorization and interleaving. You can now use `#pragma clang loop
vectorize(enable)` as well as `vectorize(disable)`, `vectorize_width(n)`,
`interleave(enable/disable)`, and `interleave_count(n)`.
[r210330](http://reviews.llvm.org/rL210330).

* Support for the MSVC++ ABI continues with the addition of `dynamic_cast` for
MS. [r210377](http://reviews.llvm.org/rL210377).
* Support for global named registers has been expanded slightly to allow
pointer types to be held in these variables.
[r210274](http://reviews.llvm.org/rL210274).

* GCC's `-Wframe-larger-than=bytes` diagnostic is now supported.
[r210293](http://reviews.llvm.org/rL210293).

## Other project commits

* A benchmarking-only mode has been added to the testsuite
[r210251](http://reviews.llvm.org/rL210251).

* A [status page](http://libcxx.llvm.org/ts1z_status.html) for post-C++14
features in libcxx has been added.
[r210056](http://reviews.llvm.org/rL210056).

* An initial set of Makefiles has been committed to lld.
[r210177](http://reviews.llvm.org/rL210177).

* lldb gained support for inspecting enum members.
[r210046](http://reviews.llvm.org/rL210046).

* Polly can now be built without any GPLed software.
[r210176](http://reviews.llvm.org/rL210176).