[LLVMdev] LLVM Weekly - #35, Sep 1st 2014

[David Blaikie]

On Mon, Sep 1, 2014 at 10:46 AM, Alex Bradbury <asb at asbradbury.org> wrote:

> LLVM Weekly - #35, Sep 1st 2014
> ===============================
>
> If you prefer, you can read a HTML version of this email at
> <http://llvmweekly.org/issue/35>.
>
> Welcome to the thirty-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.
>
> As I mentioned in a previous issue, I am involved in the
> [lowRISC](http://lowrisc.org) projects to produce a fully open-source SoC.
> Just a quick reminder that [we are
> hiring](http://www.jobs.cam.ac.uk/job/4665/), and you have just over a
> week to
> get your application in.
>
> ## News and articles from around the web
>
> LLVM/Clang 3.5 is inching ever closer to release. The fourth and hopefully
> final release candidate is [available for
> testing](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76370).
>
> Quarks Lab have published a [preview of
> SCAF](
> http://blog.quarkslab.com/scaf-source-code-analysis-framework-based-on-clang-pre-alpha-preview.html
> ),
> a Source Code Analysis Framework built on Clang. It promises a release
> soon.
>
> The [VMKit project website](http://vmkit.llvm.org/) has this week been
> [updated](http://reviews.llvm.org/rL216831) to mark the project as
> retired.
> VMKit was a project to implement virtual machines such as a JVM on top of
> LLVM. People interested in restarting the project are encouraged to get in
> touch with Gaël Thomas.
>
> AMD and Microsoft have [released a C++ AMP compiler targeting version 1.2
> of
> the specification](
> http://sdtimes.com/amd-announces-heterogeneous-c-amp-language-developers/
> ).
> The C++ AMP (Accelerated Massive Parallelism) compiler is of course based
> on
> LLVM and Clang, and can be [found
> here](https://bitbucket.org/multicoreware/cppamp-driver-ng/wiki/Home).
>
>
> ## On the mailing lists
>
> * Manuel Klimek has provided a [quick run-down of the state of his work on
> Clang C++ refactoring
> tools](http://article.gmane.org/gmane.comp.compilers.clang.devel/38657).
> He
> reports there are a number of standalone, single-use refacotring tools but
> more work needs to be done on generalising and integrating them. The plan
> is
> to push more of these tools to tools-extra (where clang-rename lives), make
> them integratable as a library, integrate them into libclang and then
> integrate them into projects like [ycmd](https://github.com/Valloric/ycmd
> ).
>
> * Robin Morisset has been working on optimisations for lowering of atomics
> and
> has [asked for input on a fence elimination
> algorithm](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76400)
> he's been thinking about. He has outlined two possible implementation
> routes
> he would like feedback on.
>
> * A discussion about [improving
> llvm-objdump](
> http://article.gmane.org/gmane.comp.compilers.llvm.devel/76278),
> kicked off by Steve King, makes an interesting read. I'm looking forward
> to a
> future with a more featureful llvm-objdump that prints symbols of branch
> targets by default.
>
> * David Blaikie has started a discussion about [supporting -gmlt in
> LLVM/Clang](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76341
> ).
> Vital to having any chance of understanding this thread is to know that
> gmlt
> refers to debug info containing 'minimal line tables', a feature that [was
> added to GCC a while
> back](https://gcc.gnu.org/ml/gcc-patches/2011-04/msg02075.html).
>

Sorry, yeah - I might've assumed a fair bit of specific context there.
Actually Alexey already previously implemented -gmlt, but -gfission sort of
breaks users who really want to find at least backtrace-necessary data in
the original binary, rather than in side-files (dwo/dwp). To address that
I'll be moving the logic for implementing -gmlt down from the frontend
(clang) to LLVM.

In doing so, once it's in the backend, it can be more selective (rather
than simpler debug info describing /every/ function - we can just describe
the functions with inlined functions within them) & reduce even the normal
-gmlt a bit.


>
> * I linked last week to the mailing list thread on removing static
> initializers for command line options and regrettably was unable to
> summarise
> the extensive discussion. The bad news is discussion has continued at a
> rapid
> pace, but thankfully Chandler Carruth has rather helpfully [sumarised the
> main
> outcomes of the
> discussion](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76279
> ).
> It's also worth reading [this
> thread](http://article.gmane.org/gmane.comp.compilers.llvm.devel/76382)
> for an
> idea of what the new infrastructure might look like.
>
>
> ## LLVM commits
>
> * The AArch64 backend learned about v4f16 and v8f16 operations,
> [r216555](http://reviews.llvm.org/rL216555).
>
> * The LLVM CMake build system now includes support for building with
> UndefinedBehaviourSanitizer. [r216701](http://reviews.llvm.org/rL216701).
>
>
> ## Clang commits
>
> * The `-fdevirtualize` and `-fdevirtualize-speculatively` flags are now
> recognised (and ignored) for compatibility with GCC.
> [r216477](http://reviews.llvm.org/rL216477).
>
> * Some Google Summer of Code work has started to land. In particular, the
> Clang static analyzer gained initial infrastructure to support for
> synthesizing function implementations from external model files. See the
> commit message for full details on the intent of this feature.
> [r216550](http://reviews.llvm.org/rL216550).
>
> * Support was added for capturing variable length arrays in C++11 lambda
> expressions. [r216649](http://reviews.llvm.org/rL216649).
>
>
> ## Other project commits
>
> * LLDB gained documentation on its internal register numbering scheme.
> [r216372](http://reviews.llvm.org/rL216372).
>
> * LLDB is making progress towards AArch64 support.
> [r216736](http://reviews.llvm.org/rL216737).
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140901/38961be2/attachment.html>