[LLVMdev] LLVM Weekly - #1, Jan 6th 2014

[Alex Bradbury]

LLVM Weekly - #1, Jan 6th 2014
==============================

Welcome to the inaugural issue of LLVM Weekly, a weekly newsletter (published
every Monday) covering developments in LLVM, Clang, and related projects. I've
been a long time lurker on the LLVM and Clang mailing lists and have been
using LLVM extensively in my PhD research for the past 4 years. I thought it
might be worthwhile to produce something to help keep track of what's going on
in LLVM development, and here we are. I'm very open to suggestions and will
probably play a bit with the format and content over the next few weeks. I'd
also be very grateful for any suggestions of things to mention or cover.
Subscribe to future issues at <http://llvmweekly.org>, and please 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.

Find the HTML version of this issue at http://llvmweekly.org/issue/1

## News and articles from around the web

LLVM 3.4 was released <http://llvm.org/releases/3.4/docs/ReleaseNotes.html>.
The release notes do a far better and more thorough job of summarising the key
changes than I could, so I point you there for more information.

EuroLLVM 2014 has been announced. It will take place April 7th-8th in
Edinburgh Scotland. Registration will open soon, now is the time to submit
your proposals for talks, workshops, lightning talks or posters. The call for
participation is at
<http://article.gmane.org/gmane.comp.compilers.llvm.devel/69221> and the
homepage for the event is at <http://llvm.org/devmtg/2014-04/>.

In a recent mailing list post I came across a link to this rather excellent
article on mapping high-level constructions to LLVM IR by Mikael Lyngvig.
<http://llvm.lyngvig.org/Articles/Mapping-High-Level-Constructs-to-LLVM-IR>.
The document is already in a good state, but Mikael is inviting review or
contributions, particularly from those who implement frontends of higher level
languages targetting LLVM IR.

Andrew Wilkins writes about recent changes to llgo, a Go frontend for LLVM.
<http://blog.awilkins.id.au/2014/01/llgo-on-ssa.html>

DZone predicts the end of the GNU gcc era
<http://java.dzone.com/articles/2014-look-magic-crystal-ball>

Phoronix published a series of benchmarks comparing Clang 3.4 performance
against GCC 4.9
<http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers&num=1>

## On the mailing lists

* Rafael Espíndola removed support for the 's' modifier in a DataLayout
specification in commit [r198287](http://llvm-reviews.chandlerc.com/rL198287)
and so writes how to work around this if your out of tree target relied on
that modifier <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69143>

* Chandler Carruth asks a question about flags for instructions in .td files
<http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69118>. From the
answers, it seems like confusion can arise from the fact flags don't need to
be listed explicitly if they are inferred from patterns. Hal Finkel suggests
auditing the generated tablegen output directly.

* Jon Pry has posted an RFC suggesting to change the datalayout for the Radeon
R600 backend <http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69130>.
The problem is that the r600 datalayout description currently claims native
integer widths of 32 and 64 bit, but support for 64 bit arithmetic is actually
limited to getelementptr-like load/store operations (although this point is
debated in replies to the thread).  The patch proposes to simply claim native
32 bit integer width only, though alternative solutions are proposed in thread
responses.

* Andrew Trick outlines an algorithm to estimate cycles taken on an
out-of-order core
<http://article.gmane.org/gmane.comp.compilers.llvm.devel/69145>

* Build bot fatigue
<http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69103> is causing
problems. In short the build bots are sending too many messages, and slow
servers keep on sending messages for issues that were fixed already resulting
in a low signal to noise ratio. There was a suggestion to move to the phased
builder infrastructure as used by Apple. There were additional complaints from
Alp about large numbers of emails from ARM buildbots about errors such as out
of disk <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69200>.
Renato Golin responds explaining that due to the lack of commercial ARM server
hardware they have to rely on development boards or consumer laptops, which
may not be the most reliable under heavy load.

* Snehasish Kumar asks about using DependenceAnalysis to find both
loop-independent and loop-carried dependences, receiving some useful
responses. <http://article.gmane.org/gmane.comp.compilers.llvm.devel/69094>

* David Fang posts a summary of the current status of the PowerPC-Darwin ports
<http://article.gmane.org/gmane.comp.compilers.llvm.devel/69196>. An
extensively detailed status page is also available at
<http://www.csl.cornell.edu/~fang/sw/llvm/>

* Swarup Kumar Sahoo points to the current giri code
<https://github.com/liuml07/giri> in response to a question about how to trace
every value and address used by a program.
<http://article.gmane.org/gmane.comp.compilers.llvm.devel/69150>

* Tim Northover provides a straight forward overview of what to do in order to
disable loop unrolling and function inlining, and where the source to the
relevant passes can be found
<http://article.gmane.org/gmane.comp.compilers.llvm.devel/69213>

* Michael Schlottke asks for advice about LibTools vs LibClang+Python for some
C++ refactoring tasks.
<http://article.gmane.org/gmane.comp.compilers.clang.devel/34050> The mailing
list is overwhelmingly in favour of using LibTooling, though it does have the
downside that nobody has produced Python bindings to it yet.

## LLVM commits

Warning: this is an opinionated, unscientific highlighting of certain LLVM
commits. I may have missed your favourite change - apologies.

* An initial ASM parser was added to the SPARC backend
<http://llvm-reviews.chandlerc.com/rL198484>. The backend also learned to
handle atomics loads/stores <http://llvm-reviews.chandlerc.com/rL198286>.

* Various AVX512 (currently only available in Xeon Phi CPUs) intrinsics were
added <http://llvm-reviews.chandlerc.com/rL198277>,
<http://llvm-reviews.chandlerc.com/rL198557>

* ARM: For compatibility with GNU as, aliases for old (deprecated) FP
mnemonics were added <http://llvm-reviews.chandlerc.com/rL198172>.
Additionally, softvfp was added to the list of supported FPU names
<http://llvm-reviews.chandlerc.com/rL198313>

* The LLVM mangler, used to determin the symbol name of a GlobalValue no
longer requires linking with Target. This means the DataLayout now contains a
specification for the name mangling behaviour.
<http://llvm-reviews.chandlerc.com/rL198438>

* tryInstructionSplit() has been made less aggressive
<http://llvm-reviews.chandlerc.com/rL198369>

* In the world of tablegen, a bug with the use of multiclass parameters was
fixed <http://llvm-reviews.chandlerc.com/rL198348>

* A confusion between `Value*` identify and 'value' equivalence was corrected
in BasicAA <http://llvm-reviews.chandlerc.com/rL198290>

## Clang commits

* RecursiveASTVisitor and DataRecursiveASTVisitor learned to visit attributes
<http://llvm-reviews.chandlerc.com/rL198224>,
<http://llvm-reviews.chandlerc.com/rL198249>

* ExpectAndConsume will diagnose more errors automatically
<http://llvm-reviews.chandlerc.com/rL198270>

* The formatter gained an option to avoid splitting certain sorts of comments
which have special meaning (e.g. pragmas) across multiple lines
<http://llvm-reviews.chandlerc.com/rL198310>. It can also format short enums
on to a single line <http://llvm-reviews.chandlerc.com/rL198558>

* The VBTableBuilder class was moved from CodeGen to AST with the long-term
goal of using it to compute virtual fuction table names
<http://llvm-reviews.chandlerc.com/rL198380>

* CreateAnalysisConsumer is added to the static analyzer's public interface as
a way to get at its ASTConsumer. <http://llvm-reviews.chandlerc.com/rL198426>

* Virtual base class table mangling is now more compatible with MSVC202+
<http://llvm-reviews.chandlerc.com/rL198462>

* The IdempotentOperations checker was killed as it has various known issues
and nobody has come forwards to fix them.
<http://llvm-reviews.chandlerc.com/rL198476>

* `dump()` function definitions are now only marked as used in debug builds.
This will enable more stripping of dead code in release builds resulting in
smaller filesize. <http://llvm-reviews.chandlerc.com/rL198489>

* Previously, clang could be tortured by providing a K and R style function
declaration with a missing semicolon, e.g. `void knrNoSemi(i) int i { }` which
would result in a long stream of errors covering the rest of the input file.
It now recognises this error and presents a single error
<http://llvm-reviews.chandlerc.com/rL198540>.

## Other project commits

* Building libclc with LLVM 3.5 was fixed
<http://llvm-reviews.chandlerc.com/rL198167>

* In libcxx, the clz/ctz family of functions are now implemented for when
building with Visual C++ on Win32 or Win64.
<http://llvm-reviews.chandlerc.com/rL198481>

* The PollyCananicalizePass was introduced. This is a ModulePass that
schedules the Polly canonicalization passes.
<http://llvm-reviews.chandlerc.com/rL198376>