Hey neat, I've been wanting something like this for a while.<br><br><div>Thanks!</div><div><br></div><div>-eric</div><br><div>On Mon Jan 06 2014 at 2:51:31 PM, Alex Bradbury <<a href="mailto:asb@asbradbury.org">asb@asbradbury.org</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">LLVM Weekly - #1, Jan 6th 2014<br>
==============================<br>
<br>
Welcome to the inaugural issue of LLVM Weekly, a weekly newsletter (published<br>
every Monday) covering developments in LLVM, Clang, and related projects. I've<br>
been a long time lurker on the LLVM and Clang mailing lists and have been<br>
using LLVM extensively in my PhD research for the past 4 years. I thought it<br>
might be worthwhile to produce something to help keep track of what's going on<br>
in LLVM development, and here we are. I'm very open to suggestions and will<br>
probably play a bit with the format and content over the next few weeks. I'd<br>
also be very grateful for any suggestions of things to mention or cover.<br>
Subscribe to future issues at <<a href="http://llvmweekly.org" target="_blank">http://llvmweekly.org</a>>, and please pass it on<br>
to anyone else you think may be interested. Please send any tips or feedback<br>
to <<a href="mailto:asb@asbradbury.org" target="_blank">asb@asbradbury.org</a>>, or @llvmweekly or @asbradbury on Twitter.<br>
<br>
Find the HTML version of this issue at <a href="http://llvmweekly.org/issue/1" target="_blank">http://llvmweekly.org/issue/1</a><br>
<br>
## News and articles from around the web<br>
<br>
LLVM 3.4 was released <<a href="http://llvm.org/releases/3.4/docs/ReleaseNotes.html" target="_blank">http://llvm.org/releases/3.4/<u></u>docs/ReleaseNotes.html</a>>.<br>
The release notes do a far better and more thorough job of summarising the key<br>
changes than I could, so I point you there for more information.<br>
<br>
EuroLLVM 2014 has been announced. It will take place April 7th-8th in<br>
Edinburgh Scotland. Registration will open soon, now is the time to submit<br>
your proposals for talks, workshops, lightning talks or posters. The call for<br>
participation is at<br>
<<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69221" target="_blank">http://article.gmane.org/<u></u>gmane.comp.compilers.llvm.<u></u>devel/69221</a>> and the<br>
homepage for the event is at <<a href="http://llvm.org/devmtg/2014-04/" target="_blank">http://llvm.org/devmtg/2014-<u></u>04/</a>>.<br>
<br>
In a recent mailing list post I came across a link to this rather excellent<br>
article on mapping high-level constructions to LLVM IR by Mikael Lyngvig.<br>
<<a href="http://llvm.lyngvig.org/Articles/Mapping-High-Level-Constructs-to-LLVM-IR" target="_blank">http://llvm.lyngvig.org/<u></u>Articles/Mapping-High-Level-<u></u>Constructs-to-LLVM-IR</a>>.<br>
The document is already in a good state, but Mikael is inviting review or<br>
contributions, particularly from those who implement frontends of higher level<br>
languages targetting LLVM IR.<br>
<br>
Andrew Wilkins writes about recent changes to llgo, a Go frontend for LLVM.<br>
<<a href="http://blog.awilkins.id.au/2014/01/llgo-on-ssa.html" target="_blank">http://blog.awilkins.id.au/<u></u>2014/01/llgo-on-ssa.html</a>><br>
<br>
DZone predicts the end of the GNU gcc era<br>
<<a href="http://java.dzone.com/articles/2014-look-magic-crystal-ball" target="_blank">http://java.dzone.com/<u></u>articles/2014-look-magic-<u></u>crystal-ball</a>><br>
<br>
Phoronix published a series of benchmarks comparing Clang 3.4 performance<br>
against GCC 4.9<br>
<<a href="http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers&num=1" target="_blank">http://www.phoronix.com/scan.<u></u>php?page=article&item=llvm34_<u></u>gcc49_compilers&num=1</a>><br>

<br>
## On the mailing lists<br>
<br>
* Rafael Espíndola removed support for the 's' modifier in a DataLayout<br>
specification in commit [r198287](<a href="http://llvm-reviews.chandlerc.com/rL198287" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198287</a>)<br>
and so writes how to work around this if your out of tree target relied on<br>
that modifier <<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69143" target="_blank">http://article.gmane.org/<u></u>gmane.comp.compilers.llvm.<u></u>devel/69143</a>><br>
<br>
* Chandler Carruth asks a question about flags for instructions in .td files<br>
<<a href="http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69118" target="_blank">http://thread.gmane.org/<u></u>gmane.comp.compilers.llvm.<u></u>devel/69118</a>>. From the<br>
answers, it seems like confusion can arise from the fact flags don't need to<br>
be listed explicitly if they are inferred from patterns. Hal Finkel suggests<br>
auditing the generated tablegen output directly.<br>
<br>
* Jon Pry has posted an RFC suggesting to change the datalayout for the Radeon<br>
R600 backend <<a href="http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69130" target="_blank">http://thread.gmane.org/<u></u>gmane.comp.compilers.llvm.<u></u>devel/69130</a>>.<br>
The problem is that the r600 datalayout description currently claims native<br>
integer widths of 32 and 64 bit, but support for 64 bit arithmetic is actually<br>
limited to getelementptr-like load/store operations (although this point is<br>
debated in replies to the thread).  The patch proposes to simply claim native<br>
32 bit integer width only, though alternative solutions are proposed in thread<br>
responses.<br>
<br>
* Andrew Trick outlines an algorithm to estimate cycles taken on an<br>
out-of-order core<br>
<<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69145" target="_blank">http://article.gmane.org/<u></u>gmane.comp.compilers.llvm.<u></u>devel/69145</a>><br>
<br>
* Build bot fatigue<br>
<<a href="http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69103" target="_blank">http://thread.gmane.org/<u></u>gmane.comp.compilers.llvm.<u></u>devel/69103</a>> is causing<br>
problems. In short the build bots are sending too many messages, and slow<br>
servers keep on sending messages for issues that were fixed already resulting<br>
in a low signal to noise ratio. There was a suggestion to move to the phased<br>
builder infrastructure as used by Apple. There were additional complaints from<br>
Alp about large numbers of emails from ARM buildbots about errors such as out<br>
of disk <<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69200" target="_blank">http://article.gmane.org/<u></u>gmane.comp.compilers.llvm.<u></u>devel/69200</a>>.<br>
Renato Golin responds explaining that due to the lack of commercial ARM server<br>
hardware they have to rely on development boards or consumer laptops, which<br>
may not be the most reliable under heavy load.<br>
<br>
* Snehasish Kumar asks about using DependenceAnalysis to find both<br>
loop-independent and loop-carried dependences, receiving some useful<br>
responses. <<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69094" target="_blank">http://article.gmane.org/<u></u>gmane.comp.compilers.llvm.<u></u>devel/69094</a>><br>
<br>
* David Fang posts a summary of the current status of the PowerPC-Darwin ports<br>
<<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69196" target="_blank">http://article.gmane.org/<u></u>gmane.comp.compilers.llvm.<u></u>devel/69196</a>>. An<br>
extensively detailed status page is also available at<br>
<<a href="http://www.csl.cornell.edu/~fang/sw/llvm/" target="_blank">http://www.csl.cornell.edu/~<u></u>fang/sw/llvm/</a>><br>
<br>
* Swarup Kumar Sahoo points to the current giri code<br>
<<a href="https://github.com/liuml07/giri" target="_blank">https://github.com/liuml07/<u></u>giri</a>> in response to a question about how to trace<br>
every value and address used by a program.<br>
<<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69150" target="_blank">http://article.gmane.org/<u></u>gmane.comp.compilers.llvm.<u></u>devel/69150</a>><br>
<br>
* Tim Northover provides a straight forward overview of what to do in order to<br>
disable loop unrolling and function inlining, and where the source to the<br>
relevant passes can be found<br>
<<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69213" target="_blank">http://article.gmane.org/<u></u>gmane.comp.compilers.llvm.<u></u>devel/69213</a>><br>
<br>
* Michael Schlottke asks for advice about LibTools vs LibClang+Python for some<br>
C++ refactoring tasks.<br>
<<a href="http://article.gmane.org/gmane.comp.compilers.clang.devel/34050" target="_blank">http://article.gmane.org/<u></u>gmane.comp.compilers.clang.<u></u>devel/34050</a>> The mailing<br>
list is overwhelmingly in favour of using LibTooling, though it does have the<br>
downside that nobody has produced Python bindings to it yet.<br>
<br>
## LLVM commits<br>
<br>
Warning: this is an opinionated, unscientific highlighting of certain LLVM<br>
commits. I may have missed your favourite change - apologies.<br>
<br>
* An initial ASM parser was added to the SPARC backend<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198484" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198484</a>>. The backend also learned to<br>
handle atomics loads/stores <<a href="http://llvm-reviews.chandlerc.com/rL198286" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198286</a>>.<br>
<br>
* Various AVX512 (currently only available in Xeon Phi CPUs) intrinsics were<br>
added <<a href="http://llvm-reviews.chandlerc.com/rL198277" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198277</a>>,<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198557" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198557</a>><br>
<br>
* ARM: For compatibility with GNU as, aliases for old (deprecated) FP<br>
mnemonics were added <<a href="http://llvm-reviews.chandlerc.com/rL198172" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198172</a>>.<br>
Additionally, softvfp was added to the list of supported FPU names<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198313" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198313</a>><br>
<br>
* The LLVM mangler, used to determin the symbol name of a GlobalValue no<br>
longer requires linking with Target. This means the DataLayout now contains a<br>
specification for the name mangling behaviour.<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198438" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198438</a>><br>
<br>
* tryInstructionSplit() has been made less aggressive<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198369" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198369</a>><br>
<br>
* In the world of tablegen, a bug with the use of multiclass parameters was<br>
fixed <<a href="http://llvm-reviews.chandlerc.com/rL198348" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198348</a>><br>
<br>
* A confusion between `Value*` identify and 'value' equivalence was corrected<br>
in BasicAA <<a href="http://llvm-reviews.chandlerc.com/rL198290" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198290</a>><br>
<br>
## Clang commits<br>
<br>
* RecursiveASTVisitor and DataRecursiveASTVisitor learned to visit attributes<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198224" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198224</a>>,<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198249" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198249</a>><br>
<br>
* ExpectAndConsume will diagnose more errors automatically<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198270" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198270</a>><br>
<br>
* The formatter gained an option to avoid splitting certain sorts of comments<br>
which have special meaning (e.g. pragmas) across multiple lines<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198310" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198310</a>>. It can also format short enums<br>
on to a single line <<a href="http://llvm-reviews.chandlerc.com/rL198558" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198558</a>><br>
<br>
* The VBTableBuilder class was moved from CodeGen to AST with the long-term<br>
goal of using it to compute virtual fuction table names<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198380" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198380</a>><br>
<br>
* CreateAnalysisConsumer is added to the static analyzer's public interface as<br>
a way to get at its ASTConsumer. <<a href="http://llvm-reviews.chandlerc.com/rL198426" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198426</a>><br>
<br>
* Virtual base class table mangling is now more compatible with MSVC202+<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198462" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198462</a>><br>
<br>
* The IdempotentOperations checker was killed as it has various known issues<br>
and nobody has come forwards to fix them.<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198476" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198476</a>><br>
<br>
* `dump()` function definitions are now only marked as used in debug builds.<br>
This will enable more stripping of dead code in release builds resulting in<br>
smaller filesize. <<a href="http://llvm-reviews.chandlerc.com/rL198489" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198489</a>><br>
<br>
* Previously, clang could be tortured by providing a K and R style function<br>
declaration with a missing semicolon, e.g. `void knrNoSemi(i) int i { }` which<br>
would result in a long stream of errors covering the rest of the input file.<br>
It now recognises this error and presents a single error<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198540" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198540</a>>.<br>
<br>
## Other project commits<br>
<br>
* Building libclc with LLVM 3.5 was fixed<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198167" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198167</a>><br>
<br>
* In libcxx, the clz/ctz family of functions are now implemented for when<br>
building with Visual C++ on Win32 or Win64.<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198481" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198481</a>><br>
<br>
* The PollyCananicalizePass was introduced. This is a ModulePass that<br>
schedules the Polly canonicalization passes.<br>
<<a href="http://llvm-reviews.chandlerc.com/rL198376" target="_blank">http://llvm-reviews.<u></u>chandlerc.com/rL198376</a>><br>
<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</blockquote>