llvm dev - Dec 2015 - LLVM Weekly - #101, Dec 7th 2015

LLVM Weekly - #101, Dec 7th 2015
===============================
If you prefer, you can read a HTML version of this email at
<http://llvmweekly.org/issue/101>.

Welcome to the one hundred and 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

The implementation of the Swift programming language is [now open
source](https://swift.org/blog/welcome/). Rather than being a simple code
dump, development will now occur out in the open with [external contributions
encouraged](https://swift.org/contributing/). If you haven't already, now
might be a good time to watch Joseph Groff and Chris Lattner's [talk on the
Swift Intermediate Language](https://www.youtube.com/watch?v=Ntj8ab-5cvE).

Rui Ueyama [wrote about the new LLD ELF
linker](http://blog.llvm.org/2015/11/new-elf-linker-from-llvm-project.html) on
the official LLVM blog.

The Visual C++ team have released [Clang with Microsoft
CodeGen](http://blogs.msdn.com/b/vcblog/archive/2015/12/04/introducing-clang-with-microsoft-codegen-in-vs-2015-update-1.aspx).
This uses the Clang parser along with the code generator and optimizer from
Visual C++. The majority of the Clang and LLVM changes will be contributed
back upstream.

Alex Denisov wrote about [using the LLVM API with
Swift](http://lowlevelbits.org/how-to-use-llvm-api-with-swift/).

If you haven't already submitted your talk proposal for the LLVM devroom at
FOSDEM, you've now got a little more time. [Get your submission in by this
Friday](http://lists.llvm.org/pipermail/llvm-dev/2015-December/092897.html).


## On the mailing lists

* Swift team members have started discussions about upstreaming their changes
to [LLVM](http://lists.llvm.org/pipermail/llvm-dev/2015-December/093006.html),
[Clang](http://lists.llvm.org/pipermail/cfe-dev/2015-December/046335.html),
and
[LLDB](http://lists.llvm.org/pipermail/lldb-dev/2015-December/009010.html).
The Clang changes include the addition of an 'API notes' feature which
has
seen some interest from other developers. This can be used to associate
certain attributes with functions from system headers through an external YAML
file, which is of course much more pragmatic than expecting system headers on
all supported platforms to be updated.

* Vaivaswatha Nagaraj observes that [malloc and realloc don't have the
doesNotAccessMemory/onlyReadsMemory attributes
set](http://lists.llvm.org/pipermail/llvm-dev/2015-December/092919.html), and
that this makes GlobalsAA much less effective. As was pointed out in the
ensuing discussion, these attributes wouldn't be correct for malloc and
realloc but it would perhaps make sense to add a new attribute. Vaivaswatha
[penned an RFC on an HasInaccessibleState
attribute](http://lists.llvm.org/pipermail/llvm-dev/2015-December/093008.html).
This has generated a lot of discussion and alternate proposals but no
conclusion yet.

* Christof Douma has posted an [RFC on adding execute only support to the ARM
code
generator](http://lists.llvm.org/pipermail/llvm-dev/2015-December/093021.html).
This means the compiler will not generate data accesses in to the code
section.

* Oliver Stannard has posted an [RFC on supporting position-independent code
on ARM
for small embedded
systems](http://lists.llvm.org/pipermail/llvm-dev/2015-December/093022.html).
In read-only position independence (ROPI), code and read-only data is accessed
PC-relative with the offsets known at static link time. In read-write position
independence (RWPI), read-write data is accessed relative to the static base
register (R9).

* This week's bikeshedding thread is on [the naming convention for LLVM
intrinsics](http://lists.llvm.org/pipermail/llvm-dev/2015-December/092876.html).
The proposal is to standardise on using `.` as a separator. There are some
suggestions that `_` be allowed in words.

* How can you recompile functions at different optimisation levels? Lang Hames
[provides a sample doing this using the Orc
API](http://lists.llvm.org/pipermail/llvm-dev/2015-December/092945.html).


## LLVM commits

* llc and opt gained an option to run all passes twice. This is intended to
help show up bugs that occur when using the same pass manager to compile
multiple modules. [r254774](http://reviews.llvm.org/rL254774).

* An initial prototype for llvm-dwp has been committed. This will eventually
be a tool for building a DWARF package file out of a number of .dwo split
debug files.
[r254355](http://reviews.llvm.org/rL254355).

* All weight-based interfaces in MachineBasicBlock have now been replaced with
probability-based interfaces. [r254377](http://reviews.llvm.org/rL254377).

* LLVM's STLExtras gained a range-based version of `std::any_of` and
`std::find`. [r254391](http://reviews.llvm.org/rL254391),
[r254390](http://reviews.llvm.org/rL254390).

* `llvm.get.dynamic.area.offset.{i32,264}` intrinsics have been added. These
can be used to get the address of the most recent dynamic alloca.
[r254404](http://reviews.llvm.org/rL254404).

* The X86 backend gained a new pass to reduce code size by removing redundant
address recalculations for LEA. [r254712](http://reviews.llvm.org/rL254712).

* The WebAssembly backend now has initial support for varargs.
[r254799](http://reviews.llvm.org/rL254799).


## Clang commits

* Design docs have been added for forward-edge CFI for indirect calls.
[r254464](http://reviews.llvm.org/rL254464).

* The `pass_object_size` attribute was added to Clang. This intended to be
used to work around cases where `__builtin_object_size` doesn't function.
[r254554](http://reviews.llvm.org/rL254554).

* Documentation was added for UndefinedBehaviorSanitizer.
[r254733](http://reviews.llvm.org/rL254733).


## Other project commits

* LLD now supports the `R_MIPS_HI16/LO16` relocations.
[r254461](http://reviews.llvm.org/rL254461).

* libomp can now make use of libhwloc on Unix to discover topology of the host
system. [r254320](http://reviews.llvm.org/rL254320).