[LLVMdev] LLVM Weekly - #31, Aug 4th 2014

Alex Bradbury asb at asbradbury.org
Mon Aug 4 09:16:50 PDT 2014


LLVM Weekly - #31, Aug 4th 2014
===============================

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

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

Renato Golin has posted a [summary of feedback from his talk on LLVM and GCC
collaboration at the GNU Tools
Cauldron](http://article.gmane.org/gmane.comp.compilers.llvm.devel/75207).
This both summarises the main areas he's looking for collaboration, and the
feedback that people gave at the event or afterwards.

This blog post describes [how to use Obfuscator-LLVM to to obfuscate Android
NDK
binaries](http://fuzion24.github.io/android/obfuscation/ndk/llvm/o-llvm/2014/07/27/android-obfuscation-o-llvm-ndk/).


## On the mailing lists

* Johannes Kapfhammer, a Google Summer of Code student has [posted an RFC on
adding a fuzzy parser for highlighting
C++](http://article.gmane.org/gmane.comp.compilers.clang.devel/38105). The
Clang parser can't be used for this as it may be highlighting incomplete
snippets where not all types or functions are included. It was pointed out in
responses that this is similar to clang-format's parser, but apparently this
parser is not easily reusable and very tied to the clang-format
implementation.

* In response to a query about whether there is interest in a performance
tracking BOF at the LLVM Dev meeting, Renato Golin has posted a [summary of
related issues discussed at the last meeting and progress made on
them](http://article.gmane.org/gmane.comp.compilers.llvm.devel/75410).

* John Kåre Alsaker posted a question about [adding a stack probe function
attribute](http://article.gmane.org/gmane.comp.compilers.llvm.devel/75230).
This would be used for languages like Rust that attempt to detect stack
overflow with the use of a guard page. Philip Reames responded with [a number
of thoughts on this
feature](http://article.gmane.org/gmane.comp.compilers.llvm.devel/75399).

* Daniel Stewart has [implemented ELF/AArch64 support for
lld](http://article.gmane.org/gmane.comp.compilers.llvm.devel/75350) and is
looking for how to upstream it. People are happy for a single patch to be
posted for review.

* In response to a question about documentation for adding builders to the
LLVM buildbot service, Dan Liew has posted a [summary of how he has done
it](http://article.gmane.org/gmane.comp.compilers.llvm.devel/75355). He's
looking for feedback on whether this is the best way to do things.

* John Kåre Alsaker has asked for feedback on [enhancing BasicAliasAnalysis
for Rust](http://article.gmane.org/gmane.comp.compilers.llvm.devel/75231).
Rust's restrictions on aliasing are not currenly fully taken advantage of.
Both [Hal
Finkel](http://article.gmane.org/gmane.comp.compilers.llvm.devel/75260) and
[Cameron
Zwarich](http://article.gmane.org/gmane.comp.compilers.llvm.devel/75286)
respond with thoughts on how to proceed.

* Tom Stellard [proposes renaming the R600 target to
AMDGPU](http://article.gmane.org/gmane.comp.compilers.llvm.devel/75214). The
motivation is that the backend has the name since the R600 was the first AMD
GPU targeted, but it has added support for all AMD GPUs since then. There
seems to be agreement this would be a sensible renaming.


## LLVM commits

* FastISel for AArch64 saw a number of improvements, including support for
shift-immediate, arithmetic with overflow intrinsics.
[r214345](http://reviews.llvm.org/rL214345),
[r214348](http://reviews.llvm.org/rL214348), and more.

* The SLPVectorizer has seen a largeish commit that implements an "improved
scheduling algorithm". Sadly the commit message offers no further details.
[r214494](http://reviews.llvm.org/rL214494).

* TargetInstrInfo gained `isAsCheapAsMove` which takes a MachineInstruction
and returns true if that instruction is as cheap as a move instruction.
[r214158](http://reviews.llvm.org/rL214158).

* LLVM libraries can now be exported as importable CMake targets, making it
easier for those building LLVM-based projects. This is now documented.
[r214077](http://reviews.llvm.org/rL214077).

* Release notes for PowerPC changes during 3.5 development have been
committed. [r214403](http://reviews.llvm.org/rL214403).

* Initial work towards supporting debug locations for fragmented variables
(e.g. by-value struct arguments passed in registers) has been committed.
[r214576](http://reviews.llvm.org/rL214576).


## Clang commits

* Work on support for the MSVC ABI continues. Clang will now consider required
alignment constraints on fields. [r214274](http://reviews.llvm.org/rL214274).

* AddressSanitizer now passes source-level information from Clang to ASan
using metadata rather than by creating global variables.
[r214604](http://reviews.llvm.org/rL214604).

* The PowerPC backend now support selection of the ELFv1/ELFv2 ABI via the
`-mabi=` option. [r214074](http://reviews.llvm.org/rL214074).


## Other project commits

* lld gained support for interworking between thumb and ARM code with Mach-O
binaries. [r214140](http://reviews.llvm.org/rL214140).

* A massive ABI testsuite (contributed by Sony) has been committed to the
test-suite repo. [r214126](http://reviews.llvm.org/rL214126).




More information about the llvm-dev mailing list