Alex Bradbury via llvm-dev
2016-Apr-04 11:19 UTC
[llvm-dev] LLVM Weekly - #118, Apr 4th 2016
LLVM Weekly - #118, Apr 4th 2016 =============================== If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/118>. Welcome to the one hundred and eighteenth 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 Almost all slides from the recent EuroLLVM conference are [now available online](http://llvm.org/devmtg/2016-03/) for your enjoyment. Some readers my be interested in a new paper about the 'LifeJacket' tool for [verifying precise floating-point optimisations in LLVM](http://arxiv.org/abs/1603.09290). Christian Neumüller has written a [new tool for syntax highlighting and cross-referencing C and C++ source](https://github.com/oberon00/synth) using libclang. ## On the mailing lists * Chandler Carruth suggests that just like commits that break codegen are immediately reverted, [commits that introduce large, especially super-linear compile time regressions should be reverted](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097849.html). There's a lot of agreement in the general principle in replies, though some point out that much of the slowdown across the past few LLVM and Clang versions is due to a large number of small changes. * James Molloy is interested in discussing [how LLVM could learn the size of a particular std::vector](http://lists.llvm.org/pipermail/llvm-dev/2016-April/097877.html) and omit unnecessary checks etc. * Nick Johnson has a [couple of questions about IfConversion in LLVM](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097755.html). They haven't been answered yet, but I know I'd be interested in the answer. * Russell Wallace has kicked off a very useful thread about [generating calls to existing functions from the JIT](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097675.html). * Zachary Turner is interested in [people's feelings on requiring a minimum of MSVC 2015 to compile LLVM and Clang](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097756.html). The general feeling so far is that it's too early for this, as typically the policy is to support the last two major MSVC releases. * Hans Wennborg has kindly highlighted a [recent API change to TargetFrameLowering::eliminateCallFramePseudoInstr](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097844.html) that will be of interest to maintainers of out-of-tree backends. * Matt Masten has posted an RFC on [vectorizing loops with calls to math functions using SVML](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097862.html) (Intel's short vector math library). * Eric Christopher has posted an RFC on [migrating debug type information generation from the backends to the frontend](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097773.html). * Ke Bai's [memory scope proposal](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097355.html) hasn't really seen any responses up to now. Philip Reames does [share some feedback](http://lists.llvm.org/pipermail/llvm-dev/2016-March/097726.html), but notes it's unlikely this proposal could realistically be merged in to LLVM unless there is more interest. If this is an area that interests you, then please do have a good read of Ke's proposal. ## LLVM commits * The Lanai backend has landed. [r264578](http://reviews.llvm.org/rL264578). * A new `llvm.experimental.guard` intrinsic has been added. As described in the accompanying documentation, along with deoptimization operand bundles this allows frontends to express guards or checks on optimistic assumptions made during compilation. [r264976](http://reviews.llvm.org/rL264976). * Support for a number of new Altivec instructions has been added. Amazingly, this includes BCD (Binary Coded Decimal) instructions. [r264568](http://reviews.llvm.org/rL264568). * The concept of MachineFunctionProperties has been introduced, with the first property being AllVRegsAllocated. This allows passes to declare that they require a particular property, in this case requiring that they be run after regalloc. [r264593](http://reviews.llvm.org/rL264593). * On X86, push will now be used in preference to mov at all optimisation levels (before it was only enabled for `-Os`). [r264966](http://reviews.llvm.org/rL264966). * LLVM's support library can now compute SHA1 hashes. This is used to implement a 'build-id'. [r265094](http://reviews.llvm.org/rL265094), [r265095](http://reviews.llvm.org/rL265095). * When metadata is only referenced in a single function, it will now be emitted just in that function block. The aim of this is to improve the potential of lazy-loading. [r265226](http://reviews.llvm.org/rL265226). ## Clang commits * The Lanai backend is now supported in the Clang driver. [r264655](http://reviews.llvm.org/rL264655). * libTooling gained a handy formatAndApplyAllReplacements function. [r264745](http://reviews.llvm.org/rL264745). ## Other project commits * Parts of LLD are starting to use the new Error handling. [r264910](http://reviews.llvm.org/rL264910), [r264921](http://reviews.llvm.org/rL264921), [r264924](http://reviews.llvm.org/rL264924), and more. * Infrastructure was added to LLD for generating thunks (as required on platforms like MIPS when calling PIC code from non-PIC). [r265059](http://reviews.llvm.org/rL265059).