llvm dev - Nov 2015 - LLVM Weekly - #98, Nov 16th 2015

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

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

This week's issue comes to you from Vienna where I'm just about to head
home
from a short break (so apologies if it's a little later than usual and
perhaps
a little less detailed). I'll admit that nobody has actually written in to
beg
that LLVM Weekly share travel tips, but I will say that Vienna is a beautiful
city that's provided lots to do over the past few days. If you're
visiting, I
can strongly recommend [Salm Bräu](http://www.salmbraeu.com/home/) for good
beer and food.


## News and articles from around the web

All of the [LLVM Dev Meeting
Videos](https://www.youtube.com/playlist?list=PL_R5A0lGi1AA4Lv2bBFSwhgDaHvvpVU21)
are now up, and will stay up. This includes [Chris Lattner and Joseph
Groff's
talk on Swift's IR](https://www.youtube.com/watch?v=Ntj8ab-5cvE). You can
also
find most of the slides [here](http://llvm.org/devmtg/2015-10/slides/). The
folks at Quarkslab have also [posted a trip
report](http://blog.quarkslab.com/llvm_dev_meeting.html).

The big news this week is that code derived from NVIDIA's PGI Fortran
compiler
[is to be open-sourced and a production-grade Fortran front-end to LLVM
produced](https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology).
This project is a collaboration between the US NNSA (National Nuclear Security
Administration), NVIDIA, and the Lawrence Livermore, Sandia, and Los Alamos
national laboratories. Hal Finkel has [shared a little more on the LLVM
mailing
list](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092404.html).
With a source code release not due for about another year, where does this
leave the existing [Flang](https://github.com/llvm-flang/flang) efforts? The
hope is that [parts of Flang will be merged with the PGI
release](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092422.html).
Douglas Miles from the PGI team has also [shared a
mini-FAQ](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092438.html).
Fortran announcement

Bjarne Stroustrup has shared a [detailed trip
report](https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report)
from the last C++ Standards Meeting.

This post over at the Include Security Blog [delves in to some details of
support for the SafeStack buffer overflow protection in
LLVM](http://blog.includesecurity.com/2015/11/LLVM-SafeStack-buffer-overflowprotection.html).

At the official LLVM blog, a new post gives a very useful guide on [how to
reduce your testcases using bugpoint and custom
scripts](http://blog.llvm.org/2015/11/reduce-your-testcases-with-bugpoint-and.html).
As the post notes, bugpoint is a very powerful tool but can be difficult to
use.


## On the mailing lists

* Do you maintain an out-of-tree target? Does your out-of-tree target have a
huge number of subregisters and depends on imprecise lanemasks being
available? If so, [Matthias Braun wants to hear from
you](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092238.html).
Speak up now if the proposed change may affect you.

* Geoff Berry is [proposing some more work on
devirtualization](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092376.html).
In particular, he wants to propagate `llvm.assume` across function calls. He
also asks what else is required to enable Clang's `-fstrict-vtable-pointers`
by default, which [Piotr Padlewski and Richard Smith provide detailed
responses
to](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092384.html).

* Cong Hou has posted an RFC on [adding a vector reduction add
instruction](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092379.html)
to LLVM IR. There hasn't been much feedback yet, but David Li [questions
whether the effect could be modelled with simpler
instructions/intrinsics](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092398.html).

* Ben Langmuir has posted an [RFC on whether modules specified in a module map
file should shadow implicitly discovered
modules](http://lists.llvm.org/pipermail/cfe-dev/2015-November/045999.html).


## LLVM commits

* LLVM's autoconf-based build system is now officially deprecated, with the
CMake build system being preferred.
[r252520](http://reviews.llvm.org/rL252520).

* Do you want to compile CUDA code with Clang and LLVM? There's now some
[handy documentation describing how to do
so](http://llvm.org/docs/CompileCudaWithLLVM.html). See also [Jingyue's
talk](https://www.youtube.com/watch?v=JHfb8z-iSYk) from the recent LLVM Dev
Meeting. [r252660](http://reviews.llvm.org/rL252660).

* A simple MachineInstruction SSA pass for PowerPC has been added. The
implementation is short and straight-forward, so worth a read if you want to
do some MI-level peephole optimisations for your target.
[r252651](http://reviews.llvm.org/rL252651).

* Basic support for AArch64's address tagging has been added. In AArch64,
the
top 8 bits of an address can be used to store extra metadata with these bits
being masked out before going through address translation.
[r252573](http://reviews.llvm.org/rL252573).

* The Hexagon backend now supports assembly parsing.
[r252443](http://reviews.llvm.org/rL252443).

* The CMake build system gained a new LLVMExternalProjectUtils module. As an
example, this is used with the LLVM test suite which can be set up to be
rebuilt whenever the in-tree clang or lld change. This could also be used with
compiler-rt or libcxx. [r252747](http://reviews.llvm.org/rL252747).

* An 'empty token' is now defined (written as `token empty`) for when
using
tokens in LLVM IR. [r252811](http://reviews.llvm.org/rL252811).

* LibFuzzer gained a new experimental search heuristic, drill. As the comment
in FuzzerLoop.cpp explains, this will 1) read+shuffle+execute+minimize the
corpus, 2) choose a random unit, 3) reset the coverage, 4) start fuzzing as if
the chosen unit was the only element of the corpus, 5) reset the coverage
again when done, 6) merge the newly created corpus into the original one.
[r252838](http://reviews.llvm.org/rL252838).

* A BITREVERSE SelectionDAG node and a set of `llvm.bitreverse.*` intrinsics
have been introduced. The intention is that backends should no longer have to
reimplement similar code to match instruction patterns to their own ISA's
bitreverse instruction. See also the patch to the ARM backend that replaces
ARMISD::RBIT with ISD::BITREVERSE.
[r252878](http://reviews.llvm.org/rL252878),
[r253047](http://reviews.llvm.org/rL253047).


## Clang commits

* Support for `__attribute__(internal_linkage)` was added. This is much like
C's static keyword, but applies to C++ class methods.
[r252648](http://reviews.llvm.org/rL252648).

* Clang now supports GCC's `__auto_type` extension, with a few minor
enhancements. [r252690](http://reviews.llvm.org/rL252690).


## Other project commits

* libcxx gained initial support for building with mustl libc. Primarily this
is a new CMake option, necessary as Musl doesn't provide a macro to indicate
its presense. [r252457](http://reviews.llvm.org/rL252457)).

> On Nov 16, 2015, at 05:30, Alex Bradbury via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> * LLVM's autoconf-based build system is now officially deprecated, with
the
> CMake build system being preferred.
> [r252520](http://reviews.llvm.org/rL252520).
Is there a metabug in bugzilla that is tracking bugs that are blocking
transition to using cmake?  Or is there some other way that packagers can
indicate issues that should be addressed before the autoconf build system is
removed?

eg: https://llvm.org/bugs/show_bug.cgi?id=19465
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4109 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151128/0a453ecc/attachment.bin>

On 29 November 2015 at 01:50, Jeremy Huddleston Sequoia
<jeremyhu at apple.com> wrote:
>
>> On Nov 16, 2015, at 05:30, Alex Bradbury via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> * LLVM's autoconf-based build system is now officially deprecated,
with the
>> CMake build system being preferred.
>> [r252520](http://reviews.llvm.org/rL252520).
>
> Is there a metabug in bugzilla that is tracking bugs that are blocking
transition to using cmake?  Or is there some other way that packagers can
indicate issues that should be addressed before the autoconf build system is
removed?
>
> eg: https://llvm.org/bugs/show_bug.cgi?id=19465
Chris Bieneman has been posting regular updates to the list on the
current status, listing issues viewed as 'blocking'. e.g. the recent
RFC http://lists.llvm.org/pipermail/llvm-dev/2015-November/092150.html
or late October update
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091798.html.

I don't think this information has all been entered in to bugzilla,
but a tracking bug could make sense if it doesn't already exist.
Responding to the RFC on removing autoconf thread with any outstanding
issues would also be a good idea.

Best,

Alex