LLVM Weekly - #38, Sep 22nd 2014 =============================== If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/38>. Welcome to the thirty-eighth 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. I've been at PyConUK this past weekend so I'm afraid it's another slightly shorter than normal issue. I've been talking about [Pyland](http://www.pyland.org), a programming game that aims to teach children programming in Python (and of course, runs on Raspberry Pi). ## News and articles from around the web A paper has recently been published about [Harmony](http://arcade.cs.columbia.edu/harmony). In the words of the authors "Harmony is an open source tool (built as an LLVM pass) that creates a new kind of application profile called Parallel Block Vectors, or PBVs. PBVs track dynamic program parallelism at basic block granularity to expose opportunities for improving hardware design and software performance." Their most recent [paper on ParaShares](http://arcade.cs.columbia.edu/parashares-europar14.pdf) describes how they find the most 'important' basic blocks in multithreaded programs. Richard Pennington has written up [some more thoughts on cross compilation configuration for Clang](http://ellcc.org/blog/?p=13246). [Clike](https://github.com/combinatorylogic/clike) is a low-level programming language with an extensible syntax based on C. It of course targets LLVM. If you want your Emacs editor to automatically disassemble LLVM bitcode inside Emacs buffers, then [autodisass-llvm-bitcode](https://github.com/gbalats/autodisass-llvm-bitcode) is for you. ## On the mailing lists * Stephen Wu has published an RFC regarding [exhaustive bitcode compatibility tests for IR features](http://article.gmane.org/gmane.comp.compilers.llvm.devel/77010). The proposal involves testing every existing IR feature so that backward compatibility can be tested and it will become obvious when it is broken inadvertently. * If you're wondering about the current status of compiling glibc with Clang/LLVM, Kostya Serebryany [has the answer](http://article.gmane.org/gmane.comp.compilers.llvm.devel/77025). There are about ten instances of nested functions and four of VLAIS, with some patches waiting to be reviewed by upstream. * Daniel Stewart has [suggested postponing various passes to the linking stage when using LTO](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76915). There's agreement on this, suggesting that vectorisation and inlining should be delayed. * Christophe Duvernois [asks whether LLVM link against miniz rather than zlib](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76887). If you're interested in a long discussion about the disadvantages of checking in dependencies locally to a codebase, this is the thread for you. ## LLVM commits * The LLVM MC layer can now write BigObj-style COFF object files. [r217812](http://reviews.llvm.org/rL217812). * X86AtomicExpandPass has been removed in favour of using the generic AtomicExpandHooks (which now has the necessary hooks). [r217928](http://reviews.llvm.org/rL217928). * llvm-cov's internal API has been reworked. [r217975](http://reviews.llvm.org/rL217975). ## Clang commits * Clang can now use 'response files' when calling other tools when the length of the command line exceeds system limits. [r217792](http://reviews.llvm.org/rL217792). * The `-Wbind-to-temporary-copy` warning is no longer on by default. [r218008](http://reviews.llvm.org/rL218008). * Clang's thread safety analysis gained `-Wthread-safety-reference` which warns when a guarded variable is passed by reference as a function argument. [r218087](http://reviews.llvm.org/rL218087). ## Other project commits * libcxx gained some support for using newlib as its C library. [r218144](http://reviews.llvm.org/rL218144).