Alex Bradbury via llvm-dev
2015-Nov-16 10:30 UTC
[llvm-dev] LLVM Weekly - #98, Nov 16th 2015
LLVM Weekly - #98, Nov 16th 2015 =============================== If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/98>. Welcome to the ninety-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. This week's issue comes to you from Vienna where I'm just about to head home from a short break (so apologies if it's a little later than usual and perhaps a little less detailed). I'll admit that nobody has actually written in to beg that LLVM Weekly share travel tips, but I will say that Vienna is a beautiful city that's provided lots to do over the past few days. If you're visiting, I can strongly recommend [Salm Bräu](http://www.salmbraeu.com/home/) for good beer and food. ## News and articles from around the web All of the [LLVM Dev Meeting Videos](https://www.youtube.com/playlist?list=PL_R5A0lGi1AA4Lv2bBFSwhgDaHvvpVU21) are now up, and will stay up. This includes [Chris Lattner and Joseph Groff's talk on Swift's IR](https://www.youtube.com/watch?v=Ntj8ab-5cvE). You can also find most of the slides [here](http://llvm.org/devmtg/2015-10/slides/). The folks at Quarkslab have also [posted a trip report](http://blog.quarkslab.com/llvm_dev_meeting.html). The big news this week is that code derived from NVIDIA's PGI Fortran compiler [is to be open-sourced and a production-grade Fortran front-end to LLVM produced](https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology). This project is a collaboration between the US NNSA (National Nuclear Security Administration), NVIDIA, and the Lawrence Livermore, Sandia, and Los Alamos national laboratories. Hal Finkel has [shared a little more on the LLVM mailing list](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092404.html). With a source code release not due for about another year, where does this leave the existing [Flang](https://github.com/llvm-flang/flang) efforts? The hope is that [parts of Flang will be merged with the PGI release](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092422.html). Douglas Miles from the PGI team has also [shared a mini-FAQ](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092438.html). Fortran announcement Bjarne Stroustrup has shared a [detailed trip report](https://isocpp.org/blog/2015/11/kona-standards-meeting-trip-report) from the last C++ Standards Meeting. This post over at the Include Security Blog [delves in to some details of support for the SafeStack buffer overflow protection in LLVM](http://blog.includesecurity.com/2015/11/LLVM-SafeStack-buffer-overflowprotection.html). At the official LLVM blog, a new post gives a very useful guide on [how to reduce your testcases using bugpoint and custom scripts](http://blog.llvm.org/2015/11/reduce-your-testcases-with-bugpoint-and.html). As the post notes, bugpoint is a very powerful tool but can be difficult to use. ## On the mailing lists * Do you maintain an out-of-tree target? Does your out-of-tree target have a huge number of subregisters and depends on imprecise lanemasks being available? If so, [Matthias Braun wants to hear from you](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092238.html). Speak up now if the proposed change may affect you. * Geoff Berry is [proposing some more work on devirtualization](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092376.html). In particular, he wants to propagate `llvm.assume` across function calls. He also asks what else is required to enable Clang's `-fstrict-vtable-pointers` by default, which [Piotr Padlewski and Richard Smith provide detailed responses to](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092384.html). * Cong Hou has posted an RFC on [adding a vector reduction add instruction](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092379.html) to LLVM IR. There hasn't been much feedback yet, but David Li [questions whether the effect could be modelled with simpler instructions/intrinsics](http://lists.llvm.org/pipermail/llvm-dev/2015-November/092398.html). * Ben Langmuir has posted an [RFC on whether modules specified in a module map file should shadow implicitly discovered modules](http://lists.llvm.org/pipermail/cfe-dev/2015-November/045999.html). ## LLVM commits * LLVM's autoconf-based build system is now officially deprecated, with the CMake build system being preferred. [r252520](http://reviews.llvm.org/rL252520). * Do you want to compile CUDA code with Clang and LLVM? There's now some [handy documentation describing how to do so](http://llvm.org/docs/CompileCudaWithLLVM.html). See also [Jingyue's talk](https://www.youtube.com/watch?v=JHfb8z-iSYk) from the recent LLVM Dev Meeting. [r252660](http://reviews.llvm.org/rL252660). * A simple MachineInstruction SSA pass for PowerPC has been added. The implementation is short and straight-forward, so worth a read if you want to do some MI-level peephole optimisations for your target. [r252651](http://reviews.llvm.org/rL252651). * Basic support for AArch64's address tagging has been added. In AArch64, the top 8 bits of an address can be used to store extra metadata with these bits being masked out before going through address translation. [r252573](http://reviews.llvm.org/rL252573). * The Hexagon backend now supports assembly parsing. [r252443](http://reviews.llvm.org/rL252443). * The CMake build system gained a new LLVMExternalProjectUtils module. As an example, this is used with the LLVM test suite which can be set up to be rebuilt whenever the in-tree clang or lld change. This could also be used with compiler-rt or libcxx. [r252747](http://reviews.llvm.org/rL252747). * An 'empty token' is now defined (written as `token empty`) for when using tokens in LLVM IR. [r252811](http://reviews.llvm.org/rL252811). * LibFuzzer gained a new experimental search heuristic, drill. As the comment in FuzzerLoop.cpp explains, this will 1) read+shuffle+execute+minimize the corpus, 2) choose a random unit, 3) reset the coverage, 4) start fuzzing as if the chosen unit was the only element of the corpus, 5) reset the coverage again when done, 6) merge the newly created corpus into the original one. [r252838](http://reviews.llvm.org/rL252838). * A BITREVERSE SelectionDAG node and a set of `llvm.bitreverse.*` intrinsics have been introduced. The intention is that backends should no longer have to reimplement similar code to match instruction patterns to their own ISA's bitreverse instruction. See also the patch to the ARM backend that replaces ARMISD::RBIT with ISD::BITREVERSE. [r252878](http://reviews.llvm.org/rL252878), [r253047](http://reviews.llvm.org/rL253047). ## Clang commits * Support for `__attribute__(internal_linkage)` was added. This is much like C's static keyword, but applies to C++ class methods. [r252648](http://reviews.llvm.org/rL252648). * Clang now supports GCC's `__auto_type` extension, with a few minor enhancements. [r252690](http://reviews.llvm.org/rL252690). ## Other project commits * libcxx gained initial support for building with mustl libc. Primarily this is a new CMake option, necessary as Musl doesn't provide a macro to indicate its presense. [r252457](http://reviews.llvm.org/rL252457)).
Jeremy Huddleston Sequoia via llvm-dev
2015-Nov-29 01:50 UTC
[llvm-dev] metabug tracking blockers for the cmake transition
> On Nov 16, 2015, at 05:30, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > * LLVM's autoconf-based build system is now officially deprecated, with the > CMake build system being preferred. > [r252520](http://reviews.llvm.org/rL252520).Is there a metabug in bugzilla that is tracking bugs that are blocking transition to using cmake? Or is there some other way that packagers can indicate issues that should be addressed before the autoconf build system is removed? eg: https://llvm.org/bugs/show_bug.cgi?id=19465 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4109 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151128/0a453ecc/attachment.bin>
Alex Bradbury via llvm-dev
2015-Nov-29 08:54 UTC
[llvm-dev] metabug tracking blockers for the cmake transition
On 29 November 2015 at 01:50, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote:> >> On Nov 16, 2015, at 05:30, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> * LLVM's autoconf-based build system is now officially deprecated, with the >> CMake build system being preferred. >> [r252520](http://reviews.llvm.org/rL252520). > > Is there a metabug in bugzilla that is tracking bugs that are blocking transition to using cmake? Or is there some other way that packagers can indicate issues that should be addressed before the autoconf build system is removed? > > eg: https://llvm.org/bugs/show_bug.cgi?id=19465Chris Bieneman has been posting regular updates to the list on the current status, listing issues viewed as 'blocking'. e.g. the recent RFC http://lists.llvm.org/pipermail/llvm-dev/2015-November/092150.html or late October update http://lists.llvm.org/pipermail/llvm-dev/2015-October/091798.html. I don't think this information has all been entered in to bugzilla, but a tracking bug could make sense if it doesn't already exist. Responding to the RFC on removing autoconf thread with any outstanding issues would also be a good idea. Best, Alex