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

Mon Jan 6 20:11:17 PST 2014

This is great! Reminds me of kerneltrap.org ... :) Someone is still trying to review that at http://kerneltrap.net !

Sameer.

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
> Behalf Of Alex Bradbury
> Sent: Tuesday, January 07, 2014 4:19 AM
> To: LLVM Developers Mailing List
> Subject: [LLVMdev] LLVM Weekly - #1, Jan 6th 2014
> 
> 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_compi
> lers&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>
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev