Alex Bradbury via llvm-dev
2015-Oct-26 12:24 UTC
[llvm-dev] LLVM Weekly - #95, Oct 26th 2015
LLVM Weekly - #95, Oct 26th 2015 =============================== If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/95>. Welcome to the ninety-fifth 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 C++ Standardization Committee just finished up their most recent meeting, and STL (Stephan T. Lavavej) has [provided a useful summary](https://www.reddit.com/r/cpp/comments/3q4agc/c17_progress_update_oct_2015/). Herb Sutter has also [posted a trip report](http://herbsutter.com/2015/10/25/2568/). The HHVM team have posted an [update on the status of LLVM code generation in HHVM](http://hhvm.com/blog/10205/llvm-code-generation-in-hhvm). They managed to get LLVM to equal the performance of their custom backend, but are not going to deploy the LLVM backend to production for now. They're no longer actively working on the LLVM backend, but hope to ensure it doesn't regress. Hal Finkel is [proposing an LLVM social in Austin on the evening of November 15th](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091612.html). There should be a high density of LLVM users due to the [LLVM in HPC workshop](http://llvm-hpc2-workshop.github.io/). ## On the mailing lists * The biggest discussion this week in the LLVM community is the [proposed change to the Apache license](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html). One motivation is that some companies feel blocked from contributing due to the wording in the patent section of the LLVM developer policy, though see the linked message for a full summary. Concerns were raised about the fact that Apache 2 is incompatible with the GPLv2 and that [license complexity may put off contributors, such as the FreeBSD community](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091642.html). * Robert Cox has posted an [RFC on adding the ability for LLVM to produce an inlining report](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091687.html). This report would give details on where inlining has taken place and why. Initial feedback is positive. * More information for birds of a feather sessions at the upcoming LLVM dev meeting has gone out. Kristof Beyls is running one on [performance tracking and benchmarking infrastructure](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091736.html), John Criswell on [sophisticated program analysis on LLVM IR](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091552.html), and Paul Robinson on [living downstream without drowning](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091546.html). * Gaël Jobin has a [fantastic answer](http://lists.llvm.org/pipermail/llvm-dev/2015-October/091685.html) to a question about handling intrinsics in your backend. * Louis Brandy is a Facebook employee who is [starting to work on enabling Clang module support for their C++ codebase](http://lists.llvm.org/pipermail/cfe-dev/2015-October/045706.html). He's interested in experiences from anyone on incrementally adding module maps to a large codebase. * A lot of work has been done to extend Clang's static analyzer to support interprocedural analysis. This thread [discusses the current state and path forward](http://lists.llvm.org/pipermail/cfe-dev/2015-October/045665.html). It's not giving the improvement expected (in terms of detected bugs-per-second) and the thread discusses thoughts on why. ## LLVM commits * The `TargetLowerBase::LibCall` LegalizeAction has been introduced. This allows backends to control whether they prefer expansion or conversion to a libcall. [r250826](http://reviews.llvm.org/rL250826). * The Hexagon backend continues to accumulate sophisticated target-specific optimisations. HexagonBitSimplify continues a number of transformations to perform simplifications, redundant code elimination etc. [r250868](http://reviews.llvm.org/rL250868). * The new AliasAnalysis infrastructure gained an optional 'external' AA wrapper pass, to allow users to merge in external AA results. The unit test included in the patch gives a good example of how to use this. [r250894](http://reviews.llvm.org/rL250894). * CodeGenPrepare can now transform select instructions into branches and sink expensive operands. [r250743](http://reviews.llvm.org/rL250743). * Loop rotation can now use profile data in making decisions during MachineBlockPlacement. [r250754](http://reviews.llvm.org/rL250754). * ValueTracking now has a `isKnownNonEqual` predicate. [r251012](http://reviews.llvm.org/rL251012). ## Clang commits * Basic (currently parsing and basic semantic analysis) support for the anticipated C++1z coroutine feature was added. [r250980](http://reviews.llvm.org/rL250980), [r250985](http://reviews.llvm.org/rL250985), [r250993](http://reviews.llvm.org/rL250993). * `-fvisibility=internal` is now aliased to `-fvisibility=hidden`, as LLVM doesn't currently support internal visibility. [r250954](http://reviews.llvm.org/rL250954). * Clang's static analyzer learnt to associate hashes with found issues. This hash aims to be resilient to code changes, so should be useful for suppressing false positives. [r251011](http://reviews.llvm.org/rL251011). ## Other project commits * lld gained support for lazy relocations on x86-64. [r250808](http://reviews.llvm.org/rL250808). * The new LLD ELF linker now supports the `--gc-sections` parameter. This increases the time to link Clang by 8% bus reduces the size of the output binary by 4%. [r251043](http://reviews.llvm.org/rL251043). * LLDB gained a REPL. [r250753](http://reviews.llvm.org/rL250753), [r250773](http://reviews.llvm.org/rL250773). * DWARF parsing in LLDB can now be multi-threaded, which can drastically incrase the speed of loading debug info. [r251106](http://reviews.llvm.org/rL251106).