Alex Bradbury via llvm-dev
2016-May-16 11:24 UTC
[llvm-dev] LLVM Weekly - #124, May 16th 2016
LLVM Weekly - #124, May 16th 2016 ================================ If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/124>. Welcome to the one hundred and twenty-fourth 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. ## News and articles from around the web The main news this week is the announcement of [Scala-native](http://www.scala-native.org/), an ahead-of-time compiler for Scala using LLVM. Jos Dirkens has written a [getting started guide](http://www.smartjava.org/content/getting-started-scala-native) if you want to compile it and try it out. There's also more information in the [slides from the announcement talk](https://github.com/densh/talks/blob/master/2016-05-11-scala-goes-native.pdf). ## On the mailing lists * More of the students taking part in Google Summer of Code with LLVM-related projects have introduced themselves and their plans. Vivek Pandya will be working on [interprocedural register allocation](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099492.html). Scott Egerton will be working on [capture tracking improvements](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099704.html). Jie Chen will be working on [better alias analysis, specifically improving cfl-aa](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099573.html). Matthias Reisinger will be working on [enabling polyhedral optimisations in Julia](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099471.html), and Zhengyan Liu has plans for [SAFECode memory hardening](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099600.html). * Renato Golin kicked off a discussion about [whether LLVM's release process could be better aligned with downstream users](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099541.html). This thread covered a broad range of topics and triggered a lot of discussion, but luckily there's no need to summarise it as Renato has [done the job for us](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099706.html). * Nicolai Hähnle notes that currently libLLVM.so [contains about 1.7MB in its .data.rel.ro section](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099398.html), of which about 1.3MB comes from the MCInstrDesc tables created by tablegen representing a massive number of pointers to be relocated. He suggests reducing this by using offsets instead. Reducing the relocations will both reduce binary size and increase the portion of the binary that can be mapped as shared. So far, responses to the thread are supportive of the idea. * James Knight has written a detailed post on [how it's not really possible to write an LL/SC loop guaranteed to make forward progress in LLVM IR right now](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099490.html). There are restrictions on what you can do between a load-linked and a store-conditional instruction that the code generator may not meet. * A public [llvm-foundation](http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-foundation) mailing list has been [announced](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099574.html), which to facilitate discussions related to the Foundation. * As well as the long, technically detailed and precise threads each week it's nice to highlight cases where a simple question has a simple answer. How do you register a pass as being opt-in based on a command-line flag? [Answer](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099470.html): have it run every time, but return immediately if the desired command line flag isn't present. * Sanjoy Das has shared an RFC on [adding a callee-saved register verifier](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099693.html). As is clarified later in the thread, the intention is to ensure that code not generated by LLVM (e.g. output from another JIT or hand-written assembly) properly adheres to the calling convention and doesn't clobber registers it shouldn't. The proposed pass would simply add code to check that the test values written to the callee-saved registers aren't modified. * In response to questions about pass ordering, Mehdi Amini has written a helpful description of [what exactly happens when you do opt -mymodulepass0 -myfunctionpass -mymodulepass1](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099477.html). * Konstantin Vladimirov wonders [if there's an option to force the register allocator to use as many architectural registers as possible to reduce dependencies](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099494.html). The short answer is there isn't currently, but it would be interesting to investigate. * Diana Picus has shared an RFC on [modifying llc so it no longer exits after the first error](http://lists.llvm.org/pipermail/llvm-dev/2016-May/099594.html). Generally people are in favour, and the patch should hopefully land soon (it had to be temporarily backed out after exposing some test cases failures in lldb). * Nico Weber has noted that now with AVX512, [Clang's intrinsics headers are huge](http://lists.llvm.org/pipermail/cfe-dev/2016-May/048837.html). This can cause compile time issues, for instance Nico reports building all of the v8 JS engine is 6% faster after removing the avx512 includes. The thread participants haven't yet decided on the best way forward to fix this, beyond the potential immediate step of adding include guards so AVX512 intrinsic headers aren't included when not compiling for AVX512 platforms. ## LLVM commits * The outdated guide on cross-compiling LLVM has been brought up to date. [r269054](http://reviews.llvm.org/rL269054). * The WebAssembly backend gained preliminary fast instruction selection (fast-isel) support. [r269083](http://reviews.llvm.org/rL269083), [r269203](http://reviews.llvm.org/rL269203), [r269273](http://reviews.llvm.org/rL269273). * Loop unrolling (other than in the case of explicit pragmas) is now disabled at `-Os` in LLVM. You may recall last week it was enabled for `-Os` in Clang, but with different thresholds. [r269124](http://reviews.llvm.org/rL269124). * A new cost-tracking system has been implemented for the loop unroller. [r269388](http://reviews.llvm.org/rL269388). * LLVM's Sparc backend has seen the addition of more LEON-specific features, e.g. signed and unsigned multiply-accumulate. [r268908](http://reviews.llvm.org/rL268908). * llc's `-run-pass` option will now work with any pass known to the pass registry. Previously it would silently do nothing if you specify indirectly added analysis passes or passes not present in the optimisation pipeline. [r269003](http://reviews.llvm.org/rL269003). * WebAssembly register stackification and coloring are now run very late in the optimisation pipeline. The commit message suggests it's useful to think of these passes as domain-specific liveness-based compression rather than a conventional optimisation. [r269012](http://reviews.llvm.org/rL269012). * When declaring global in textual LLVM IR, you must now assign them with e.g. `@0 = global i32 42`. [r269096](http://reviews.llvm.org/rL269096). * The internal assembler is now enabled by default for 32-bit MIPS targets. [r269560](http://reviews.llvm.org/rL269560). ## Clang commits * Clang now supports `__float128`. [r268898](http://reviews.llvm.org/rL268898). * Clang gained a new warning that triggers when casting away calling conventions from a function. [r269116](http://reviews.llvm.org/rL269116). * The recently developed include-fixer tools now has documentation. [r269167](http://reviews.llvm.org/rL269167). ## Other project commits * compiler-rt's CMake build system can now build builtins without a full toolchain, allowing you to bootstrap a cross-compiler. [r268977](http://reviews.llvm.org/rL268977). * LLD will now sort relocations to optimise dynamic linker performance. [r269066](http://reviews.llvm.org/rL269066).