Monday, September 15, 2014

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

This week's issue comes to you from sunny Tenerife. Yes, my dedication to
weekly LLVM updates is so great that I'm writing it on holiday. Enjoy! I'll
also note that I'm at PyCon UK next week where I'll be
presenting on the results of a project we had
some interns working on over the summer creating a programming game for the
Raspberry Pi.

News and articles from around the web

Not only does Pyston have a shiny new blog, they've also released version
0.2. Pyston is an implementation of
Python using LLVM, led by Dropbox. This release supports a range of language
features that weren't supported in 0.1, including support for the native C
API. The plan is to focus on performance during the development cycle for 0.3.

Sylvestre Ledru has posted a report of progress in building Debian with
Clang
following the completion of this year's Google Summer of Code projects. Now
with Clang 3.5.0 1261 packages fail to build with Clang. Sylvestre describes
how they're attacking the problem from both sides, by submitting patches to
upstream projects as well as to Clang where appropriate (e.g. to ignore some
unsupported optimisation flags rather than erroring out).

On the mailing lists

Philip Reames has started a discussion on adding optimisation hints for
'constant' loads. A
common case is where a field is initialised exactly once and then is never
modified. If this invariant could be expressed, it could improve alias
analysis as the AA pass would never consider that field to MayAlias with
something else (Philip reports that the obvious approach of using type-based
alias analysis isn't quite enough).

Hal Finkel has posted an RFC on attaching attributes to
values.
Currently, attributes such as noalias and nonnull can be attached to function
parameters, but in cases such as C++11 lambdas these can be packed up into a
structure and the attributes are lost. Some followup discussion focused on
whether these could be represented as metadata. The problem there of course is
that metadata is intended to be droppable (i.e. is semantically unimportant).
I very much like the
suggestion
from Philip Reames that the test suite should run with a pass that forcibly
drops metadata to verify it truly is safe to drop.