[LLVMdev] LLVM Weekly - #74, Jun 1st 2015

[Aaron Ballman]

On Mon, Jun 1, 2015 at 9:33 AM, Alex Bradbury <asb at asbradbury.org> wrote:
> LLVM Weekly - #74, Jun 1st 2015
> ===============================
>
> If you prefer, you can read a HTML version of this email at
> <http://llvmweekly.org/issue/74>
>
> Welcome to the seventy-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](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.
>
> You may be interested in the [second RISC-V
> workshop](https://blog.riscv.org/2015/04/registration-now-open-2nd-risc-v-workshop-june-29-30-2015/),
> which will be held in Berkeley June 29-30. Early bird registration ends today,
> but academics can register for free. My colleague Wei and I will be there
> representing [lowRISC](http://www.lowrisc.org).
>
>
> ## News and articles from around the web
>
> [MPI-Checker](https://github.com/0ax1/MPI-Checker), a static analysis tool for
> MPI code has been released. It is of course implemented using Clang's [Static
> Analyzer framework](http://clang-analyzer.llvm.org/).
>
> The LLVM-HPC2 workshop will be held on November 15th, co-located with SC15.
> The [call for
> papers](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86349) has
> been published. Submissions are due by September 1st.
>
>
> ## On the mailing lists
>
> * The discussion about improving LLD has resumed. Rui Ueyama has [written
> about his recent patch for a section-based PE/COFF
> linker](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86306). Sean
> Silva argues that [refactoring might be a better
> approach](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86333).
>
> * Hans Wennborg has shared a [preliminary release plan for LLVM/Clang
> 3.7](http://article.gmane.org/gmane.comp.compilers.clang.devel/42972). This
> would see the codebase branched on the 14th of July with a release target of
> the end of August. Tom Stellard has also shared a [schedule for the 3.6.2
> release](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86175). The
> deadline for patches is June 15 with the release date targeted for June 29th.
>
> * Teresa Johnson has posted an [updated RFC of her ThinLTO implementation
> plan](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86282). There
> are still concerns about the wrapping of LLVM bitcode in ELF. Alex Rosenberg
> suggests [implementing an objcopy replacement for LLVM and extending bitcode
> as necessary](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86313)
> as an alternative approach.
>
> * Chris Bieneman has posted a [status update on the quest to replace the
> autoconf build system with
> CMake](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86248).
>
> * Quentin Colombet is [seeking benchmark
> reports](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86222) (or
> indeed bugs!) for the recently added 'shrink wrapping'.
>
> * Matthias Braun has left a quick note for maintainers of out-of-tree targets
> that [pristine register semantics have been modified
> slightly](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86291).
>
> * Chandler Carruth has posted some thoughts on [next steps for loop unrolling
> analysis](http://article.gmane.org/gmane.comp.compilers.llvm.devel/86137).
>
>
> ## LLVM commits
>
> * Codegen for memcpy on Thumb2 has been improved to make use of load/store
> multiple (more details of how this works in the commit message, worth a read
> for those interested). [r238473](http://reviews.llvm.org/rL238473).
>
> * Popcount on x86 will now be implemented using a [lookup table in register
> technique](http://wm.ite.pl/articles/sse-popcount.html).
> [r238636](http://reviews.llvm.org/rL238636),
> [r238652](http://reviews.llvm.org/rL238652).
>
> * Work continues on reducing peak memory usage through optimisations to debug
> info. [r238364](http://reviews.llvm.org/rL238364).
>
> * Initial support for the `convergent` attribute has landed.
> [r238264](http://reviews.llvm.org/rL238264).
>
> * The documentation about the current state of LLVM's Phabricator has been
> updated along with a call for volunteers to help develop necessary
> improvements and modifications to Phabricator's PHP codebase.
> [r238295](http://reviews.llvm.org/rL238295).
>
> * MCJIT gained support for MIPS64r2 and MIPS64r6.
> [r238424](http://reviews.llvm.org/rL238424).
>
>
> ## Clang commits
>
> * Clang's handling of `-fopenmp` has been rewritten.
> [r238389](http://reviews.llvm.org/rL235111).
>
> * The user documentation on profiling has been extended.
> [r238504](http://reviews.llvm.org/rL238504).

Another Clang commit that should be called out specifically is that
__declspec is no longer treated as a core language extension by Clang,
but instead requires -fms-extensions or -fborland to be passed to
enable support for it. Support for __declspec is also enabled when
compiling CUDA code, but as a stopgap compatibility measure because
some of the CUDA headers are relying on it.
[r238238](http://reviews.llvm.org/rL238238).

~Aaron

>
>
> ## Other project commits
>
> * A new PE/COFF section-based linker has been added to lld. This follows on
> from discussions about the direction of lld and whether it makes sense to
> build on top of the atom model. The linker is able to self-link on Windows and
> is significantly faster than the current implementations (1.2 seconds vs 5
> seconds, even without multi-threading). It also takes only 250MB of RAM to
> self-link vs 2GB. [r238458](http://reviews.llvm.org/rL238458).
>
> * LLDB on Windows can now demangle Linux or Android symbols.
> [r238460](http://reviews.llvm.org/rL238460).
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev