[LLVMdev] LLVM Weekly - #54, Jan 12th 2015

[Alex Bradbury]

LLVM Weekly - #54, Jan 12th 2015
================================

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

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

As you receive this week's issue, I should be on my way to California where
I'll be presenting [lowRISC](http://www.lowrisc.org) at the RISC-V workshop in
Monterey and having a few mother meetings. I'm in SF Fri-Sun and somewhat free
on the Saturday if anyone wants to meet and chat LLVM or lowRISC/RISC-V.


## News and articles from around the web

Euro LLVM 2015 will be held on April 13th-14th in London, UK. The [call for
papers](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80291) is now
open with a deadline of 16th Feb.

Talks for the [LLVM devroom at
FOSDEM](https://fosdem.org/2015/schedule/track/llvm_toolchain/)
have been announced. The LLVM devroom is on Sunday 1st Feb. Readers will be
pleased to know this doesn't clash with [my talk on
lowRISC](https://fosdem.org/2015/schedule/event/lowrisc/) which is on the
Saturday.

Google now use [Clang for production Chrome builds on
Linux](http://blog.llvm.org/2015/01/using-clang-for-chrome-production.html).
They were previously using GCC 4.6. Compared to that baseline, performance
stayed roughly the same while binary size decreased by 8%. It would certainly
have been interesting to compare to a more recent GCC baseline. The blog post
indicates they're hopeful to use Clang in the future for building Chrome for
Windows.

Philip Reames did an interesting back of the envelope calculation about the
[cost of maintaining
LLVM](http://www.philipreames.com/Blog/2015/01/10/how-much-does-it-cost-to-maintain-llvm/).
He picked out commits which seems like they could be trivially automated and
guesstimated a cost based on developer time. The figure he arrives at is $1400
per month.

The next LLVM social for Cambridge, UK will be [on Wed 21st Jan at
7:30pm](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80341).


## On the mailing lists

* LLVM 3.6 will be [branching
soon](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80447), on 14th
January.

* Philip Reames asks [whether address space 1 is reserved on any
architecture](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80355).
It seems the answer is no, though the thread resulted in some discussion on
the use of address spaces and the ability to reserve some. Philip [had a
strawman
proposal](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80370) for
meanings of different address space numbers.

* Chandler Carruth has suggested [new IR features are needed to represent the
cases global metadata is currently used
for](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80430). Metadata
was intended to be used to hold information that can be safely dropped, though
this isn't true for e.g. module flags.

* Arch Robinson kicked off a discussion about [floating point range checks in
LLVM](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80381). This
isn't currently supported, though there's agreement it could be useful as well
as a fair amount of discussion on some of the expected subtleties.

* If you're wondering about alias instructions, Bruce Hoult has a [good
explanation](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80402).

* Note to out-of-tree backend maintainers, [get/setLoadExtAction now takes
another
parameter](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80385).

* Right now, LLDB will compile entered expressions in C++ mode. As [noted on
the lldb mailing
list](http://article.gmane.org/gmane.comp.debugging.lldb.devel/6141) this can
be problematic when e.g. debugging a C function which has a local variable
called 'this'. Greg Clayton [points out how helpful supporting C++ expressions
can be](http://article.gmane.org/gmane.comp.debugging.lldb.devel/6142), even
when debugging C code.

* A thread about the [design of the new pass
manager](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80418) has
been revived. Both Chandler Carruth and Philip Reames suggest
[BasicBlockPasses should
die](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80424).

* Philip Reames is seeking feedback on [a transformation which would convert a
loop to a loop
nest](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80386) if it
contains infrequently executed slow paths. There's some interesting discussion
in the thread, and it's also worth reading Duncan P.N. Exon Smith's
[clarification of branch weight, branch probability, block frequency, and
block bias](http://article.gmane.org/gmane.comp.compilers.llvm.devel/80472).


## LLVM commits

* An option `hoist-cheap-insts` has been added to the machine loop invariant
code motion pass to enable hosting even cheap instructions (as long as
register pressure is low). This is disabled by default.
[r225470](http://reviews.llvm.org/rL225470).

* The calculation of the unrolled loop size has been fixed. Targets may want
to re-tune their default threshold.
[r225565](http://reviews.llvm.org/rL225565),
[r225566](http://reviews.llvm.org/rL225566).

* DIE.h (datastructures for DWARF info entries) is now a public CodeGen header
rather than being private to the AsmPrinter implementation. dsymutil will make
use of it. [r225208](http://reviews.llvm.org/rL225208).

* The new pass manager now has a handy utility for generating a no-op pass
that forces a usually lazy analysis to be run.
[r225236](http://reviews.llvm.org/rL225236).

* There's been a minor change to the .ll syntax for comdats.
[r225302](http://reviews.llvm.org/rL225302).

* There have been some minor improvements to the emacs packages for LLVM and
tablegen mode. [r225356](http://reviews.llvm.org/rL225356).

* An example GCStrategy using the new statepoint infrastructure has been
added. [r225365](http://reviews.llvm.org/rL225365),
[r225366](http://reviews.llvm.org/rL225366).


## Clang commits

* A `Wself-move` warning has been introduced. Similar to `-Wself-assign`, it
will warn you when your code tries to move a value to itself.
[r225581](http://reviews.llvm.org/rL225581).

* The I, J, K, M, N, O inline assembly constraints are now checked.
[r225244](http://reviews.llvm.org/rL225244).


## Other project commits

* The libcxx test infrastructure has been refactored into separate modules.
[r225532](http://reviews.llvm.org/rL225532).

* The effort to retire InputElement in lld continues. Linker script files are
no longer represented as an InputElement.
[r225330](http://reviews.llvm.org/rL225330).

* Polly has gained a [changelog](http://polly.llvm.org/changelog.html) in
preparation of the next release.[r225264](http://reviews.llvm.org/rL225264).

* Polly has also gained a [TODO list](http://polly.llvm.org/todo.html) for its
next phase of development. [r225388](http://reviews.llvm.org/rL225388).