<div dir="ltr">Thanks, Alex.<div style>It is very useful. </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/7 Greg Fitzgerald <span dir="ltr"><<a href="mailto:garious@gmail.com" target="_blank">garious@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Awesome, super useful.  Thanks so much for doing this!<br>
<span class="HOEnZb"><font color="#888888"><br>
-Greg<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Jan 6, 2014 at 3:16 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br>
> Hey neat, I've been wanting something like this for a while.<br>
><br>
> Thanks!<br>
><br>
> -eric<br>
><br>
> On Mon Jan 06 2014 at 2:51:31 PM, Alex Bradbury <<a href="mailto:asb@asbradbury.org">asb@asbradbury.org</a>> wrote:<br>
>><br>
>> LLVM Weekly - #1, Jan 6th 2014<br>
>> ==============================<br>
>><br>
>> Welcome to the inaugural issue of LLVM Weekly, a weekly newsletter<br>
>> (published<br>
>> every Monday) covering developments in LLVM, Clang, and related projects.<br>
>> 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<br>
>> it<br>
>> might be worthwhile to produce something to help keep track of what's<br>
>> going on<br>
>> in LLVM development, and here we are. I'm very open to suggestions and<br>
>> will<br>
>> probably play a bit with the format and content over the next few weeks.<br>
>> 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<br>
>> on<br>
>> to anyone else you think may be interested. Please send any tips or<br>
>> feedback<br>
>> to <<a href="mailto:asb@asbradbury.org">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<br>
>> <<a href="http://llvm.org/releases/3.4/docs/ReleaseNotes.html" target="_blank">http://llvm.org/releases/3.4/docs/ReleaseNotes.html</a>>.<br>
>> The release notes do a far better and more thorough job of summarising the<br>
>> 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<br>
>> for<br>
>> participation is at<br>
>> <<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69221" target="_blank">http://article.gmane.org/gmane.comp.compilers.llvm.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-04/</a>>.<br>
>><br>
>> In a recent mailing list post I came across a link to this rather<br>
>> excellent<br>
>> article on mapping high-level constructions to LLVM IR by Mikael Lyngvig.<br>
>><br>
>> <<a href="http://llvm.lyngvig.org/Articles/Mapping-High-Level-Constructs-to-LLVM-IR" target="_blank">http://llvm.lyngvig.org/Articles/Mapping-High-Level-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<br>
>> level<br>
>> languages targetting LLVM IR.<br>
>><br>
>> Andrew Wilkins writes about recent changes to llgo, a Go frontend for<br>
>> LLVM.<br>
>> <<a href="http://blog.awilkins.id.au/2014/01/llgo-on-ssa.html" target="_blank">http://blog.awilkins.id.au/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/articles/2014-look-magic-crystal-ball</a>><br>
>><br>
>> Phoronix published a series of benchmarks comparing Clang 3.4 performance<br>
>> against GCC 4.9<br>
>><br>
>> <<a href="http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers&num=1" target="_blank">http://www.phoronix.com/scan.php?page=article&item=llvm34_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<br>
>> [r198287](<a href="http://llvm-reviews.chandlerc.com/rL198287" target="_blank">http://llvm-reviews.chandlerc.com/rL198287</a>)<br>
>> and so writes how to work around this if your out of tree target relied on<br>
>> that modifier<br>
>> <<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69143" target="_blank">http://article.gmane.org/gmane.comp.compilers.llvm.devel/69143</a>><br>
>><br>
>> * Chandler Carruth asks a question about flags for instructions in .td<br>
>> files<br>
>> <<a href="http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69118" target="_blank">http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69118</a>>. From the<br>
>> answers, it seems like confusion can arise from the fact flags don't need<br>
>> to<br>
>> be listed explicitly if they are inferred from patterns. Hal Finkel<br>
>> suggests<br>
>> auditing the generated tablegen output directly.<br>
>><br>
>> * Jon Pry has posted an RFC suggesting to change the datalayout for the<br>
>> Radeon<br>
>> R600 backend<br>
>> <<a href="http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69130" target="_blank">http://thread.gmane.org/gmane.comp.compilers.llvm.devel/69130</a>>.<br>
>> The problem is that the r600 datalayout description currently claims<br>
>> native<br>
>> integer widths of 32 and 64 bit, but support for 64 bit arithmetic is<br>
>> actually<br>
>> limited to getelementptr-like load/store operations (although this point<br>
>> is<br>
>> debated in replies to the thread).  The patch proposes to simply claim<br>
>> native<br>
>> 32 bit integer width only, though alternative solutions are proposed in<br>
>> 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/gmane.comp.compilers.llvm.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/gmane.comp.compilers.llvm.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<br>
>> resulting<br>
>> in a low signal to noise ratio. There was a suggestion to move to the<br>
>> phased<br>
>> builder infrastructure as used by Apple. There were additional complaints<br>
>> from<br>
>> Alp about large numbers of emails from ARM buildbots about errors such as<br>
>> out<br>
>> of disk <<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69200" target="_blank">http://article.gmane.org/gmane.comp.compilers.llvm.devel/69200</a>>.<br>
>> Renato Golin responds explaining that due to the lack of commercial ARM<br>
>> server<br>
>> hardware they have to rely on development boards or consumer laptops,<br>
>> 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.<br>
>> <<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69094" target="_blank">http://article.gmane.org/gmane.comp.compilers.llvm.devel/69094</a>><br>
>><br>
>> * David Fang posts a summary of the current status of the PowerPC-Darwin<br>
>> ports<br>
>> <<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/69196" target="_blank">http://article.gmane.org/gmane.comp.compilers.llvm.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/~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/giri</a>> in response to a question about how to<br>
>> 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/gmane.comp.compilers.llvm.devel/69150</a>><br>
>><br>
>> * Tim Northover provides a straight forward overview of what to do in<br>
>> 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/gmane.comp.compilers.llvm.devel/69213</a>><br>
>><br>
>> * Michael Schlottke asks for advice about LibTools vs LibClang+Python for<br>
>> some<br>
>> C++ refactoring tasks.<br>
>> <<a href="http://article.gmane.org/gmane.comp.compilers.clang.devel/34050" target="_blank">http://article.gmane.org/gmane.comp.compilers.clang.devel/34050</a>> The<br>
>> mailing<br>
>> list is overwhelmingly in favour of using LibTooling, though it does have<br>
>> 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.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.chandlerc.com/rL198286</a>>.<br>
>><br>
>> * Various AVX512 (currently only available in Xeon Phi CPUs) intrinsics<br>
>> were<br>
>> added <<a href="http://llvm-reviews.chandlerc.com/rL198277" target="_blank">http://llvm-reviews.chandlerc.com/rL198277</a>>,<br>
>> <<a href="http://llvm-reviews.chandlerc.com/rL198557" target="_blank">http://llvm-reviews.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.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.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<br>
>> contains a<br>
>> specification for the name mangling behaviour.<br>
>> <<a href="http://llvm-reviews.chandlerc.com/rL198438" target="_blank">http://llvm-reviews.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.chandlerc.com/rL198369</a>><br>
>><br>
>> * In the world of tablegen, a bug with the use of multiclass parameters<br>
>> was<br>
>> fixed <<a href="http://llvm-reviews.chandlerc.com/rL198348" target="_blank">http://llvm-reviews.chandlerc.com/rL198348</a>><br>
>><br>
>> * A confusion between `Value*` identify and 'value' equivalence was<br>
>> corrected<br>
>> in BasicAA <<a href="http://llvm-reviews.chandlerc.com/rL198290" target="_blank">http://llvm-reviews.chandlerc.com/rL198290</a>><br>
>><br>
>> ## Clang commits<br>
>><br>
>> * RecursiveASTVisitor and DataRecursiveASTVisitor learned to visit<br>
>> attributes<br>
>> <<a href="http://llvm-reviews.chandlerc.com/rL198224" target="_blank">http://llvm-reviews.chandlerc.com/rL198224</a>>,<br>
>> <<a href="http://llvm-reviews.chandlerc.com/rL198249" target="_blank">http://llvm-reviews.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.chandlerc.com/rL198270</a>><br>
>><br>
>> * The formatter gained an option to avoid splitting certain sorts of<br>
>> 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.chandlerc.com/rL198310</a>>. It can also format short<br>
>> enums<br>
>> on to a single line <<a href="http://llvm-reviews.chandlerc.com/rL198558" target="_blank">http://llvm-reviews.chandlerc.com/rL198558</a>><br>
>><br>
>> * The VBTableBuilder class was moved from CodeGen to AST with the<br>
>> 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.chandlerc.com/rL198380</a>><br>
>><br>
>> * CreateAnalysisConsumer is added to the static analyzer's public<br>
>> interface as<br>
>> a way to get at its ASTConsumer.<br>
>> <<a href="http://llvm-reviews.chandlerc.com/rL198426" target="_blank">http://llvm-reviews.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.chandlerc.com/rL198462</a>><br>
>><br>
>> * The IdempotentOperations checker was killed as it has various known<br>
>> issues<br>
>> and nobody has come forwards to fix them.<br>
>> <<a href="http://llvm-reviews.chandlerc.com/rL198476" target="_blank">http://llvm-reviews.chandlerc.com/rL198476</a>><br>
>><br>
>> * `dump()` function definitions are now only marked as used in debug<br>
>> builds.<br>
>> This will enable more stripping of dead code in release builds resulting<br>
>> in<br>
>> smaller filesize. <<a href="http://llvm-reviews.chandlerc.com/rL198489" target="_blank">http://llvm-reviews.chandlerc.com/rL198489</a>><br>
>><br>
>> * Previously, clang could be tortured by providing a K and R style<br>
>> function<br>
>> declaration with a missing semicolon, e.g. `void knrNoSemi(i) int i { }`<br>
>> which<br>
>> would result in a long stream of errors covering the rest of the input<br>
>> 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.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.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.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.chandlerc.com/rL198376</a>><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:LLVMdev@cs.uiuc.edu">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/mailman/listinfo/llvmdev</a><br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">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/mailman/listinfo/llvmdev</a><br>
><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">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/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Shining(╩Ě─■)<div>Changchun, Jilin, China<br><div><br></div></div></div>
</div>