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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The main news this week is the announcement of Scala-native, an ahead-of-time compiler for Scala using LLVM. Jos Dirkens has written a getting started guide if you want to compile it and try it out. There's also more information in the slides from the announcement talk.

Renato Golin kicked off a discussion about whether LLVM's release process could be better aligned with downstream users. 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.

Nicolai Hähnle notes that currently libLLVM.so contains about 1.7MB in its .data.rel.ro section, 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. 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 mailing list has been announced, 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: 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. 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.

Konstantin Vladimirov wonders if there's an option to force the register allocator to use as many architectural registers as possible to reduce dependencies. 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. 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).