<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 1, 2014 at 10:46 AM, Alex Bradbury <span dir="ltr"><<a href="mailto:asb@asbradbury.org" target="_blank">asb@asbradbury.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">LLVM Weekly - #35, Sep 1st 2014<br>
===============================<br>
<br>
If you prefer, you can read a HTML version of this email at<br>
<<a href="http://llvmweekly.org/issue/35" target="_blank">http://llvmweekly.org/issue/35</a>>.<br>
<br>
Welcome to the thirty-fifth issue of LLVM Weekly, a weekly newsletter<br>
(published every Monday) covering developments in LLVM, Clang, and related<br>
projects.LLVM Weekly is brought to you by [Alex<br>
Bradbury](<a href="http://asbradbury.org" target="_blank">http://asbradbury.org</a>).Subscribe to future issues at<br>
<<a href="http://llvmweekly.org" target="_blank">http://llvmweekly.org</a>> and pass it on to anyone else you think may be<br>
interested. Please send any tips or feedback to <<a href="mailto:asb@asbradbury.org">asb@asbradbury.org</a>>, or<br>
@llvmweekly or @asbradbury on Twitter.<br>
<br>
As I mentioned in a previous issue, I am involved in the<br>
[lowRISC](<a href="http://lowrisc.org" target="_blank">http://lowrisc.org</a>) projects to produce a fully open-source SoC.<br>
Just a quick reminder that [we are<br>
hiring](<a href="http://www.jobs.cam.ac.uk/job/4665/" target="_blank">http://www.jobs.cam.ac.uk/job/4665/</a>), and you have just over a week to<br>
get your application in.<br>
<br>
## News and articles from around the web<br>
<br>
LLVM/Clang 3.5 is inching ever closer to release. The fourth and hopefully<br>
final release candidate is [available for<br>
testing](<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/76370" target="_blank">http://article.gmane.org/gmane.comp.compilers.llvm.devel/76370</a>).<br>
<br>
Quarks Lab have published a [preview of<br>
SCAF](<a href="http://blog.quarkslab.com/scaf-source-code-analysis-framework-based-on-clang-pre-alpha-preview.html" target="_blank">http://blog.quarkslab.com/scaf-source-code-analysis-framework-based-on-clang-pre-alpha-preview.html</a>),<br>
a Source Code Analysis Framework built on Clang. It promises a release soon.<br>
<br>
The [VMKit project website](<a href="http://vmkit.llvm.org/" target="_blank">http://vmkit.llvm.org/</a>) has this week been<br>
[updated](<a href="http://reviews.llvm.org/rL216831" target="_blank">http://reviews.llvm.org/rL216831</a>) to mark the project as retired.<br>
VMKit was a project to implement virtual machines such as a JVM on top of<br>
LLVM. People interested in restarting the project are encouraged to get in<br>
touch with Gaël Thomas.<br>
<br>
AMD and Microsoft have [released a C++ AMP compiler targeting version 1.2 of<br>
the specification](<a href="http://sdtimes.com/amd-announces-heterogeneous-c-amp-language-developers/" target="_blank">http://sdtimes.com/amd-announces-heterogeneous-c-amp-language-developers/</a>).<br>
The C++ AMP (Accelerated Massive Parallelism) compiler is of course based on<br>
LLVM and Clang, and can be [found<br>
here](<a href="https://bitbucket.org/multicoreware/cppamp-driver-ng/wiki/Home" target="_blank">https://bitbucket.org/multicoreware/cppamp-driver-ng/wiki/Home</a>).<br>
<br>
<br>
## On the mailing lists<br>
<br>
* Manuel Klimek has provided a [quick run-down of the state of his work on<br>
Clang C++ refactoring<br>
tools](<a href="http://article.gmane.org/gmane.comp.compilers.clang.devel/38657" target="_blank">http://article.gmane.org/gmane.comp.compilers.clang.devel/38657</a>). He<br>
reports there are a number of standalone, single-use refacotring tools but<br>
more work needs to be done on generalising and integrating them. The plan is<br>
to push more of these tools to tools-extra (where clang-rename lives), make<br>
them integratable as a library, integrate them into libclang and then<br>
integrate them into projects like [ycmd](<a href="https://github.com/Valloric/ycmd" target="_blank">https://github.com/Valloric/ycmd</a>).<br>
<br>
* Robin Morisset has been working on optimisations for lowering of atomics and<br>
has [asked for input on a fence elimination<br>
algorithm](<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/76400" target="_blank">http://article.gmane.org/gmane.comp.compilers.llvm.devel/76400</a>)<br>
he's been thinking about. He has outlined two possible implementation routes<br>
he would like feedback on.<br>
<br>
* A discussion about [improving<br>
llvm-objdump](<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/76278" target="_blank">http://article.gmane.org/gmane.comp.compilers.llvm.devel/76278</a>),<br>
kicked off by Steve King, makes an interesting read. I'm looking forward to a<br>
future with a more featureful llvm-objdump that prints symbols of branch<br>
targets by default.<br>
<br>
* David Blaikie has started a discussion about [supporting -gmlt in<br>
LLVM/Clang](<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/76341" target="_blank">http://article.gmane.org/gmane.comp.compilers.llvm.devel/76341</a>).<br>
Vital to having any chance of understanding this thread is to know that gmlt<br>
refers to debug info containing 'minimal line tables', a feature that [was<br>
added to GCC a while<br>
back](<a href="https://gcc.gnu.org/ml/gcc-patches/2011-04/msg02075.html" target="_blank">https://gcc.gnu.org/ml/gcc-patches/2011-04/msg02075.html</a>).<br></blockquote><div><br></div><div>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. <br>
<br>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* I linked last week to the mailing list thread on removing static<br>
initializers for command line options and regrettably was unable to summarise<br>
the extensive discussion. The bad news is discussion has continued at a rapid<br>
pace, but thankfully Chandler Carruth has rather helpfully [sumarised the main<br>
outcomes of the<br>
discussion](<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/76279" target="_blank">http://article.gmane.org/gmane.comp.compilers.llvm.devel/76279</a>).<br>
It's also worth reading [this<br>
thread](<a href="http://article.gmane.org/gmane.comp.compilers.llvm.devel/76382" target="_blank">http://article.gmane.org/gmane.comp.compilers.llvm.devel/76382</a>) for an<br>
idea of what the new infrastructure might look like.<br>
<br>
<br>
## LLVM commits<br>
<br>
* The AArch64 backend learned about v4f16 and v8f16 operations,<br>
[r216555](<a href="http://reviews.llvm.org/rL216555" target="_blank">http://reviews.llvm.org/rL216555</a>).<br>
<br>
* The LLVM CMake build system now includes support for building with<br>
UndefinedBehaviourSanitizer. [r216701](<a href="http://reviews.llvm.org/rL216701" target="_blank">http://reviews.llvm.org/rL216701</a>).<br>
<br>
<br>
## Clang commits<br>
<br>
* The `-fdevirtualize` and `-fdevirtualize-speculatively` flags are now<br>
recognised (and ignored) for compatibility with GCC.<br>
[r216477](<a href="http://reviews.llvm.org/rL216477" target="_blank">http://reviews.llvm.org/rL216477</a>).<br>
<br>
* Some Google Summer of Code work has started to land. In particular, the<br>
Clang static analyzer gained initial infrastructure to support for<br>
synthesizing function implementations from external model files. See the<br>
commit message for full details on the intent of this feature.<br>
[r216550](<a href="http://reviews.llvm.org/rL216550" target="_blank">http://reviews.llvm.org/rL216550</a>).<br>
<br>
* Support was added for capturing variable length arrays in C++11 lambda<br>
expressions. [r216649](<a href="http://reviews.llvm.org/rL216649" target="_blank">http://reviews.llvm.org/rL216649</a>).<br>
<br>
<br>
## Other project commits<br>
<br>
* LLDB gained documentation on its internal register numbering scheme.<br>
[r216372](<a href="http://reviews.llvm.org/rL216372" target="_blank">http://reviews.llvm.org/rL216372</a>).<br>
<br>
* LLDB is making progress towards AArch64 support.<br>
[r216736](<a href="http://reviews.llvm.org/rL216737" target="_blank">http://reviews.llvm.org/rL216737</a>).<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div></div>