Alex Bradbury via llvm-dev
2016-Aug-22 11:28 UTC
[llvm-dev] LLVM Weekly - #138, Aug 22nd 2016
LLVM Weekly - #138, Aug 22nd 2016 ================================ If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/138>. Welcome to the one hundred and 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. ## News and articles from around the web LLVM and Clang [3.9.0-rc2 has been tagged](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103857.html). A seemingly anonymous blog post has been written introducing [new LLVM passes to increase code coverage with AFL and similar fuzzers](https://lafintel.wordpress.com/2016/08/15/circumventing-fuzzing-roadblocks-with-compiler-transformations/). These passes de-optimize code generated by LLVM. The 2016 US LLVM Developers' Meeting's [call for papers](http://llvm.org/devmtg/2016-11/#cfp) closes this Thursday, 25th August. The LLVM Foundation have also announced a [student travel grant program](http://llvm.org/devmtg/2016-11/#grant). We've announced the main track talks [schedule for the LLVM Cauldron 2016](http://llvm.org/devmtg/2016-09/#schedule). This one-day conference will take place on September 8th in Hebden Bridge, UK. If you're still weighing up whether to make the trip, you may also want to review the line-up for the [GNU Tools Cauldron](https://gcc.gnu.org/wiki/cauldron2016) which takes place over the following two days. Registration is free, so go ahead and [register now](http://llvm.org/devmtg/2016-09/#register). The next [Cambridge LLVM Social](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103934.html) will take place on Tuesday 6th September. It's timed so hopefully people will be able to attend before travelling to Hebden Bridge for the LLVM and GNU Cauldrons. ## On the mailing lists * Alex Bradbury (disclosure: that's me) posted an RFC for [inclusion of a new RISC-V backend in LLVM](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748.html). A series of patches has been submitted that introduces the MC layer, and the plan is to continue submitting changes incrementally in reviewable chunks. "Producing a series of patches that introduce RISC-V support incrementally in easy-to-review chunks with associated test cases at every point also allows us to get the maximum benefit from LLVM's code review procedure." Responses have been positive so far. * Ed Jones has posted an RFC on [adding the AAP backend to LLVM](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103807.html). [AAP](http://www.embecosm.com/resources/appnotes/#EAN13) is designed as a reference architecture representative of many deeply embedded Harvard architectures used in in industry. The thread hasn't generated much feedback yet. * Renato Golin is seeking feedback through an [RFC on the formation of a survey on the proposed GitHub move](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103862.html). This thread is attempting to hone in on a set of questions that will be most effective at getting feedback from the wider community of LLVM developers and downstream users. * Zachary Turner has [proposed a cross-platform replacement for the use of Unix utilities used in lit tests](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103713.html). He firstly notes that many lit tests that claim to require a Unix shell actually don't, given that GNUWin32 is already a dependency. Removing that GNUWin32 dependency is [also discussed](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103732.html) of course. * Eric Fiselier suggests that [LLVM release candidate binaries should not disable assertions](http://lists.llvm.org/pipermail/llvm-dev/2016-August/103680.html). Many respondents can see the argument for this, but also point out that the build configuration then wouldn't match the configuration used for the release binary. ## LLVM commits * The official policy for accepting a new LLVM backend target have now been added to the developer policy. [r278971](http://reviews.llvm.org/rL278971). * Initial documentation has been added for MemorySSA. [r278875](http://reviews.llvm.org/rL278875). * Work is being done on the aggressive dead code elimination pass to eventually support removing unnecessary control flow. [r278807](http://reviews.llvm.org/rL278807). * libFuzzer gained support for value profiling. [r278839](http://reviews.llvm.org/rL278839). * A flag has been added to disable manual alloca merging. As described in the commit message, the intent is to make use of LLVM's lifetime marker based stack coloring instead. [r278892](http://reviews.llvm.org/rL278892). * The WebAssemblyLowerEmscriptenException pass was rewritten to support setjmp/longjmp as well as exception handling. [r279075](http://reviews.llvm.org/rL279075). ## Clang commits * The concept of deferred diagnostics has been introduced. These are emitted if and only if a particular FunctionDecl is codegenned. The motivation use case is for CUDA. [r278735](http://reviews.llvm.org/rL278735). * A new checker has been added to look for loss of sign or precision in integral casts. [r278941](http://reviews.llvm.org/rL278941). * The recently added CloneDetector gained the ability to find clones that look like copy+paste errors. It looks for cases where exactly one variable is out of place compared to the original code, which likely indicates the developer forgot to rename one variable. [r279056](http://reviews.llvm.org/rL27905). ## Other project commits * A mammoth LLDB patch has introduced a StructuredData plugin type and an example user of this feature, DarwinLog. [r279202](http://reviews.llvm.org/rL279202). * The libcxx buildsystem has been updated so it can be built from the LLVM runtimes subdirectory. [r279151](http://reviews.llvm.org/rL279151).