Planet Clang

June 01, 2015

LLVM Blog

LLVM Weekly - #74, Jun 1st 2015

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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

You may be interested in the second RISC-V workshop, 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.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

MPI-Checker, a static analysis tool for MPI code has been released. It is of course implemented using Clang's Static Analyzer framework.

The LLVM-HPC2 workshop will be held on November 15th, co-located with SC15. The call for papers has been published. Submissions are due by September 1st.

On the mailing lists

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.

  • Popcount on x86 will now be implemented using a lookup table in register technique. r238636, r238652.

  • Work continues on reducing peak memory usage through optimisations to debug info. r238364.

  • Initial support for the convergent attribute has landed. r238264.

  • 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.

  • MCJIT gained support for MIPS64r2 and MIPS64r6. r238424.

Clang commits

  • Clang's handling of -fopenmp has been rewritten. r238389.

  • The user documentation on profiling has been extended. r238504.

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.

  • LLDB on Windows can now demangle Linux or Android symbols. r238460.

by Alex Bradbury (noreply@blogger.com) at June 01, 2015 01:35 PM

May 25, 2015

LLVM Blog

LLVM Weekly - #73, May 25th 2015

Welcome to the seventy-third 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

The LLVM blog has properly announced full support for OpenMP 3.1 in Clang.

The Clang-derived Zapcc has had some attention this week. It claims higher compilation speeds than the baseline Clang or other compilers. Yaron Keren, the principal developer has shared many more details about its implementation on the Clang mailing list.

On the mailing lists

LLVM commits

  • The dereferenceable_or_null attribute will now be exploited by the loop environment code motion pass. r237593.

  • Commits have started on the 'MIR serialization' project, which aims to print machine functions in a readable format. r237954.

  • A GCStrategy for CoreCLR has been committed alongside some documentation for it. r237753, r237869.

  • libFuzzer gained some more documentation. r237836.

  • libFuzzer can now be used with user-supplied mutators. r238059, r238062.

Clang commits

  • -fopenmp will turn on OpenMP support and link with libiomp5 (libgomp can alternatively be specified). r237769.

  • The -mrecip flag has been added to match GCC. r238055.

Other project commits

  • C++1z status for libcxx has been updated. r237606.

  • std::bool_constant and uninitialized_copy() was added to libcxx. r237636, r237699.

  • libcxx gained a TODO list. Plenty of tasks that might be interesting to new contributors. r237813, r237988.

  • LDB has enabled debugging of multithreaded programs on Windows and gained support for attaching to process. r237637, r237817.

by Alex Bradbury (noreply@blogger.com) at May 25, 2015 04:39 PM

May 22, 2015

LLVM Blog

OpenMP Support

OpenMP support in Clang compiler is completed! Every pragma and clause from 3.1 version of the standard is supported in full, including combined directives (like ‘#pragma omp parallel for’ and ‘#pragma omp parallel sections’).  In addition, some elements of OpenMP 4.0 are supported as well. This includes “almost complete” support for ‘#pragma omp simd” and full support for ‘#pragma omp atomic’  (combined pragmas and a couple of clauses are still missing).

OpenMP enables Clang users to harness full power of modern multi-core processors with vector units. Pragmas from OpenMP 3.1 provide an industry standard way to employ task parallelism, while ‘#pragma omp simd’ is a simple yet flexible way to enable data parallelism (aka vectorization).

Clang implementation of OpenMP standard relies on LLVM OpenMP runtime library, available at http://openmp.llvm.org/. This runtime supports ARM® architecture processors, PowerPC™ processors, 32 and 64 bit X86 processors and provides ABI compatibility with GCC and Intel's existing OpenMP compilers.

To enable OpenMP, just add ‘-fopenmp’ to the command line and provide paths to OpenMP headers and library with ‘-I <path to omp.h> -L <LLVM OpenMP library path>’.

To run a compiled program you may need to provide a path to shared OpenMP library as well:

$ export LD_LIBRARY_PATH=<OpenMP library path>:$LD_LIBRARY_PATH
or:
$ export DYLD_LIBRARY_PATH=<OpenMP library path>:$DYLD_LIBRARY_PATH
on Mac OS X.

You can confirm that the compiler works correctly by trying this simple parallel C program:

#include <omp.h>
#include <stdio.h>
int main() {
#pragma omp parallel
    printf("Hello from thread %d, nthreads %d\n", omp_get_thread_num(), omp_get_num_threads());
}

Compile it (you should see no errors or warnings):

$ clang -fopenmp -I <path to omp.h> -L <LLVM OpenMP library path> hello_openmp.c -o hello_openmp

and execute:

$ export [DY]LD_LIBRARY_PATH=<OpenMP library path>:$[DY]LD_LIBRARY_PATH
$ ./hello_openmp

You will see more than one “Hello” line with different thread numbers (note that the lines may be mixed together). If you see only one line, try setting the environment variable OMP_NUM_THREADS to some number (say 4) and try again.

Hopefully, you will enjoy using OpenMP and witness dramatic boosts of your applications’ performance!

by Alexey Bataev (noreply@blogger.com) at May 22, 2015 03:23 PM

May 18, 2015

LLVM Blog

LLVM Weekly - #72, May 18th 2015

Welcome to the seventy-second 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

Some of you may be interested that over at the lowRISC project, we've announced the full set of summer student projects we're supporting.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

The Rust programming language, which of course uses LLVM as its compiler backend, has just released version 1.0.

The next Cambridge LLVM Social will take place on Wednesday 20th May at the Cambridge Beer Festival.

On the mailing lists

LLVM commits

  • The ARM backend has been updated to use AEABI aligned function variants. r237127.

  • The heuristic for estimating the effect of complete loop unrolling has been reimplemented. r237156.

  • Statepoints are now 'patchable'. r237214.

  • Support for function entry count metadata has been added. r237260.

  • A new loop distribution pass has been born. It is off by default. r237358.

  • New SelectionDAG nodes have been added for signed/unsigned min/max. r237423.

  • A simple speculative execution pass, targeted mainly at GPUs has been added. r237459.

Clang commits

  • The little endian SPARC target has been added to clang. r237001.

  • clang-format's formatter has undergone some refactoring, which also led to a few bug fixes.r237104.

  • Documentation on adding new attributes has seen a significant update. r237268.

Other project commits

  • libcxx learnt std::experimental::sample r237264.

  • lldb has enabled multithreaded debugging on Windows. r237392.

  • lldb can now set and clear hardware watchpoints and breakpoints on AArch64. r237419.

  • lldb gained an assembly profiler for mips32. r237420.

by Alex Bradbury (noreply@blogger.com) at May 18, 2015 12:56 PM

May 11, 2015

LLVM Blog

LLVM Weekly - #71, May 11th 2015

Welcome to the seventy-first 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

The implementation of OpenMP 3.1 in Clang/LLVM is now complete. Well done to everyone involved.

Most slides from the presentations at EuroLLVM 2015 are now online. Video is coming soon.

Version 3.5.1 of Clang UPC, the Unified Parallel C compiler has been released. The main change seems to be the move to Clang/LLVM 3.5.

The Pony Language, which features an LLVM backend has recently been released. It received quite a lot of discussion on Hacker News.

Many readers might be interested in this update from the last C++ standardization committee meeting.

IBM have posted some bounties for TSAN support and MSAN support for PPC64.

On the mailing lists

LLVM commits

  • A new 'shrink-wrap' pass has been added. It attempts to insert the prologue and epilogue of a function somewhere other than the entry/exit blocks. See the commit message for a motivating example. r236507.

  • Support for the z13 processor and its vector capabilities have been added to the SystemZ backend. r236520, r236521.

  • Documentation has been written for the new masked gather and scatter intrinsics. r236721.

  • The statepoint intrinsic has been extended to allow statepoints to be marked as tranditions from GC-aware code to nonGC-aware code. r236888.

Clang commits

  • Clang support for the z13 processor was added. r236531.

  • Thread-safe initialization using the MSVC 2015 ABI has been implemented. r236697.

  • User-friendly -fsanitize-coverage= flags are now available. r236790.

Other project commits

  • libiomp's CMake has been integrated into the LLVM CMake build system, so you can now checkout libiomp and have it built alongside llvm, clang and so on. r236534.

by Alex Bradbury (noreply@blogger.com) at May 11, 2015 09:42 AM

May 04, 2015

LLVM Blog

LLVM Weekly - #70, May 4th 2015

Welcome to the seventieth 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Microsoft have announced their intention to make use of the Clang frontend on Windows.

Bjarne Stroustrup has recently been talking about potential C++17 features.

The Visual C++ developers are going to be open-sourcing their GDB/LLDB debug engine.

The projects accepted into Google Summer of Code for LLVM have been announced. Four student projects have been accepted.

The next Bay Area LLVM social is scheduled for 7pm on Thursday the 7th of May. Please sign up if you are attending.

On the mailing lists

  • Rui Ueyama has been doing quite a lot of work on LLD of late and has proposed an LLD improvement plan. In it, he proposes some major changes that would hopefully ease the path to LLD becoming a fully functional ELF, Mach-O, and PE-COFF linker. The two main proposals are to use the 'section' rather than the 'atom' model and to stop trying to bend the Unix model to work on other platforms, instead directly implementing the necessary native behaviour. There are understandably some concerns that this direction could result in LLD having to maintain essentially three linkers, but discussion is ongoing and much feedback seems positive.

  • Alex, who will be interning at Apple this summer has posted an RFC on a proposed machine level IR text serialisation format. It came out a little mangled on Gmane so you may prefer to read the pipermail rendering. A lot of the feedback revolves around the pros and cons of a YAML-based format..

  • Andrey Bokhanko suggests replacing libgomp with libiomp as the default OpenMP runtime library when using -fopenmp. Ultimately there seems to be agreement and the only issue seems to be on the library naming.

  • Nico Weber reports that although -gline-tables-only makes debug info much smaller, they've found with Chromium the resulting stackframes aren't that usable without function parameters and namespaces. The proposal is to add a new variant that does include function parameter info and namespace info.

LLVM commits

  • The LLVM performance tips document has gained another two entries. r235825, r235826.

  • llvm-symbolizer now works on Windows. r235900.

  • SelectionDAG, DAGCombiner and codegen support for masked scatter and gather has been added. r235970, r236211, r236394.

  • Debug locations have been added to all constant SelectionDAG nodes. r235989.

  • Dragonegg support has been dropped from the release script. r236077.

  • The debug info IR constructs have been renamed from MD* to DI*. Duncan suggests that if you're updating an out of tree target, it may be easiest to first get things compiling with the code from before this commit, then continue the merge. r236120.

Clang commits

  • Clang can now generate dependencies in the style accepted by the NMake and Jom build tools. r235903.

  • New AVX-512 intrinsics have been added. r235986, r236218.

  • Clang learned -Wpessimizing-move and -Wredundant-move warnings. r236075.

Other project commits

  • LLDB gained support for the SysV ABI on ARM and AArch64. r236097, r236098.

  • The LLVM test suite gained a frame_layout test. r236085.

by Alex Bradbury (noreply@blogger.com) at May 04, 2015 12:33 PM

April 27, 2015

LLVM Blog

LLVM Weekly - #69, Apr 27th 2015

Welcome to the sixty-ninth 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Ed Jones at Embecosm has written about his work to use the GCC regression suite on Clang and documented how to run the LLVM test suites on an embedded target.

GCC 5.1 has now been released. Congratulations to the GCC team. The versioning scheme is potentially confusing - 5.0 is the development version which saw a stable release as 5.1. The next minor releases will be 5.2, 5.3 etc and the next major release will be 6.1 (referred to as 6.0 during development).

On the mailing lists

  • Sanjoy Das has posted an RFC on supporting implicit null checks in LLVM. This is intended to support managed languages like Java, C#, or Go where a null check is required before using pointers.

  • Alex L interned at Apple last year, and is interning again this summer. He's posted to the list about his project, which is to develop a text-based human readable format that allows LLVM to serialize the machine-level IR. The intention is to make debug and testing easier. He welcomes any feedback or suggestions.

  • libunwind is moving to its own repository. Hopefully a git mirror will go live soon.

  • Roel Jordans gave a talk at EuroLLVM this year about his software pipelining pass. He has posted to the mailing list to give a few more details and share his source code.

  • Tom Stellard is looking to increase the number of code owners, i.e. the set of people who review patches or approve merge requests to stable branches on a certain part of the code. His plan is to start nominating new code owners based on git history whenever he gets a new stable merge request for an unowned component.

LLVM commits

  • Functions can now have metadata attachments. r235785.

  • The stack object allocation for Hexagon has been completely overhauled. r235521.

  • The vim support files have been updated. Changes include a new indentation plugin for .ll files. r235369.

  • llvm-link learned the -override option to override linkage rules. r235473.

  • There is now textual IR support for an explicit type parameter to the invoke instruction (much like for the call instruction). r235755.

Clang commits

  • Documentation has been added for SanitizerCoverage (simple code coverage using the Sanitizer tools). r235643.

  • Clang's __attribute__((aligned)) can now set alignment to a target-specific value, rather than just assuming 16 bytes on all platforms. r235397.

Other project commits

  • lld now understands --discard-locals. r235357.

  • lldb's 'operation' and 'monitor' threads on Linux have been merged in to one. r235304.

  • It's now possible to build compiler-rt for MIPS with gcc. r235299.

  • libunwind seems to have been moved into its own project. r235759.

by Alex Bradbury (noreply@blogger.com) at April 27, 2015 12:41 PM

April 21, 2015

LLVM Blog

LLVM Weekly - #68, Apr 20th 2015

Welcome to the sixty-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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Last week was of course EuroLLVM. It was good to put faces to names for a number of you, or to meet people I've only communicated with over twitter. Slides and videos should be forthcoming, but in the meantime you can read the liveblog I maintained for the talks I was able to attend. A big thank you to the organisers and all those who presented.

The highest profile news for some time in the LLVM community is that Microsoft are working on an LLVM-based compiler for .NET CoreCLR. What's more, LLILC (pronounced 'lilac') is open source, and they hope to contribute their LLVM changes upstream.

The Cerberus team are trying to find an answer to the question 'What is C in practice?, and you can help by filling out their survey.

Honza Hubička has posted a fantastic overview of the improvements to link-time and inter-procedural optimisations in GCC5, featuring figures from Firefox builds. It seems like impressive improvements have been made.

Simon Cook has written a blog post about using TableGen outside of LLVM, specifically for things like parameterisable SSH configs. Crazy? Genius? Why not both?

On the mailing lists

LLVM commits

  • The dereferenceable_or_null attribute has been born. As described in the commit message, the motivation is for managed languages such as Java. r235132.

  • A new layer was added to the Orc JIT API for applying arbitrary transforms to IR. r234805.

  • Memory intrinsics can now be tail calls. r234764.

  • A handy Python script has been added for generating C programs that have a control flow graph which is a ladder graph. The intent is to use it to test whether an algorithm expected to be linear time on the CFG really is. r234917.

  • The code for lowering switches and extracting jump tables has been rewritten, and should produce better results now. r235101.

  • Call can now take an explicit type parameter. r235145.

Clang commits

  • Clang learned -Wrange-loop-analysis, which will warn when a range-based for loop makes copies of elements in the range. r234804.

  • The preserve-bc-uselistorder option is no longer true by default, but Clang will set it for -emit-llvm or -save-temps. r234920.

  • LLVM has had a lot of changes to the debug API in the last week. This commit updates Clang for them. r235112.

Other project commits

  • Reducing the amount of template use in LLD has reduced the size of AArch64TargetHandler.cpp.o to 4.1MB, down from 21MB. r234808, r234931.

  • A large patchset has landed in lldb which adds a big chunk of the work necessary for supporting lldb on ARM. r234870.

by Alex Bradbury (noreply@blogger.com) at April 21, 2015 08:52 AM

April 14, 2015

LLVM Blog

LLILC : An LLVM based compiler for dotnet CoreCLR.

The LLILC project (we pronounce it "lilac") is a new effort started at Microsoft to produce MSIL code generators based on LLVM and targeting the open source dotnet CoreCLR. We are envisioning using the LLVM infrastructure for a number of scenarios, but our first tool is a Just in Time (JIT) compiler for CoreCLR. This new project is being developed on GitHub and you can check it out here. The rest of this post outlines the rational and goals for the project as well as our experience using LLVM.

Why a new JIT for CoreCLR?

While the CoreCLR already has JIT, we saw an opportunity to provide a new code generator that has the potential to run across all the targets and platforms supported by LLVM. To enable this, as part of our project we're opening an MSIL reader that operates directly against the same common JIT interface as the production JIT (RyuJIT). This new JIT will allow any C# program written for the .NET Core class libraries to run on any platform that CoreCLR can be ported to and that LLVM will target.

There are several ongoing efforts to compile MSIL in the LLVM community, SharpLang springs to mind. Why build another one?

When we started thinking about the fastest way to get a LLVM based code generation working we looked around at the current open source projects as well as the code we had internally. While a number of the OSS projects already targeted LLVM BitCode, no one had anything that was a close match for the CoreCLR interface. Looking at our options it was simplest for us to refactor a working MSIL reader to target BitCode then teach a existing project to support the contracts and APIs the CoreCLR uses for JITing MSIL. Using a existing MSIL reader let us quickly start using a number of building-block components that we think the community can take advantage of. This fast bootstrap for C# across multiple platforms was the idea that was the genesis of this project and the compelling reason to start a new effort. We hope LLILC will provide a useful example - and reusable components - for the community and make it easier for other projects to interoperate with the CoreCLR runtime.

Why LLVM?

Basically we think LLVM is awesome. It's already got great support across many platforms and chipsets and the community is amazingly active. When we started getting involved, just trying to stay current with the developer mailing list was a revelation! The ability for LLVM to operate as both a JIT and as an AOT compiler was especially attractive. By bringing MSIL semantics to LLVM we plan to construct a number of tools that can work against CoreCLR or some sub set of its components. We also hope the community will produce tools what we haven't thought of yet.

Tool roadmap

  • CoreCLR JIT
    • Just In Time - A classic JIT. This is expected to be throughput-challenged but will be correct and usable for bringup. Also possible to use with more optimization enabled as a higher tier JIT
    • Install-time JIT - What .NET calls NGen. This will be suitable for install-time JITing (LLVM is still slow in a runtime configuration)
  • Ahead of Time compiler. A build lab compiler that produces standalone executables, using some shared components from CoreCLR. The AOT compiler will be used to improve startup time for important command line applications like the Roslyn Compiler.
The LLIC JIT will be a functionally correct and complete JIT for the CoreCLR runtime. It may not have sufficient throughput to be a first-tier jit, but is expected to produce high-quality code and so might make a very interesting second-tier or later JIT, or a good vehicle for prototyping codegen changes to feed back into RyuJIT.

What's Actually Working

Today on Windows we have the MSIL reader & LLVM JIT implemented well enough to compile a significant number of methods in the JIT bring up tests included in CoreCLR. In these tests we compile about 90% the methods and then fall back to RyuJIT for cases we can't handle yet. The testing experience is pretty decent for developers. The tests we run can be seen in the CoreCLR test repo.
We've establish builds on Linux and Mac OSX and are pulling together mscorlib, the base .NET Core library from CoreFx, and test asset dependencies to get testing off-the-ground for those platforms.
All tests run against the CoreCLR GC in conservative mode - which scans the frame for roots - rather than precise mode. We don't yet support Exception Handling.

Architecture

Philosophically LLILC is intended to provide a lean interface between CoreCLR and LLVM. Where possible we rely on preexisting technology.

For the JIT, when we are compiling on demand, we map the runtime types and MSIL into LLVM BitCode. From there compilation uses LLVM MCJIT infrastructure to produce compiled code that is output to buffers provided by CoreCLR.

Our AOT diagram is more tentative but the basic outline is that the code generator is driven using the same interface and the JIT but that there is a static type system behind it and we build up a whole program module with in LLVM and run in a LTO like mode. Required runtime components are emitted with the output objs and the platform linker then produces the target executable. There are still a number of open questions around issues like generics that need resolution but this is our first stake in the ground.

Experience with LLVM

In the few months we've been using LLVM, we've had a really good experience but with a few caveats. Getting started with translating to BitCode has been a very straightforward experience and ramp-up time for someone with compiler experience has been very quick. The MCJIT, which we started with for our JIT, was easy to configure and get code compiled and returned to the runtime. Outside of the COFF issue discussed below, we only had to make adjustments in configuration or straightforward overrides of classes, like EEMemoryManager, to enable working code. Of the caveats, the first was simple, but the other two are going to require sustained work to bring up to the level we'd like. The first issue was a problem with Windows support in the DynamicRuntime of the MCJIT infrastructure. The last two, Precise Garbage Collection, and Exception Handling, arise because of the different semantics of managed languages. Luckily for us, people in the community have already started working in these areas so we don't have to start from zero.

COFF dynamic loader support

One of the additions we made to LLVM to unblock ourselves was to implement a COFF dynamic loader. (The patch to add RuntimeDyldCoff.{h,cpp} is through review and has been committed). This was the only addition we directly had to make to LLVM to enable bring-up of the code generator. Once this is in, we see a number of bugs in the database around Windows JIT support that should be easier to close.

Precise Garbage Collection

Precise GC is central to the CoreCLR approach to memory management. Its intent is to keep the overhead of managed memory as low as possible. It is assumed by the runtime that the JIT will generate precise information about the GC ref lifetimes and provide it with the compiled code for execution. To support this we're beginning to use the StatePoint approach, with additions to convert the standard output format to the custom format expected by CoreCLR. We share some of the same concerns that Philip Reames wrote about in the initial design of StatePoints. E.g. preservation of "GCness" through the optimizer is critical, but must not block optimizer transformations. Given this concern one of our open questions is how to enable testing to find GC holes that creep in, but also enable extra checking that can be opted into if the incoming IR contains GC pointers.
There is a more detailed document included in our repo that outlines our more-specific GC plans here.

Exception Handling

The MSIL EH model is specific to the CLR as you'd expect, but it descends in part conceptually from Windows Structured Exception Handling (SEH). In particular, the implicit exception flow from memory accesses to implement null checks, and the use of filters and funclets in the handling of exceptions, mirrors SEH (here. is an outline of C# EH) Our plans at this point are to add all checks required by MSIL as explicit compare/branch/throw sequences to better match C++ EH as well as building on the SEH support currently being put into Clang. Then, once we have correctness, see if there is a reasonable way forward that improves performance.
Like GC, there's a detailed doc outlining our specific issues and plans in the repo here

Future Work

  • More platforms. Today we're running on Windows and starting to build for Linux and Mac OSX. We'd like more.
  • Complete JIT implementation
    • More MSIL opcodes supported
    • Precise GC support
    • EH support
  • Specialized memory allocators for hosted solutions. CoreCLR has been used as a hosted solution (run in process by other programs) but to support this we need a better memory allocation story. The runtime should be able to provide a memory allocator that is used for all compilation.
  • AOT - Fully flesh out the AOT story.

by Unknown (noreply@blogger.com) at April 14, 2015 02:03 PM

April 13, 2015

OpenMP Runtime Project

New code release

We are excited to announce the next release of the Intel® OpenMP* Runtime Library at openmprtl.org. This release aligns with Intel® Parallel Studio XE 2015 Composer Edition Update 4.

New Features

  • Debugger support interface added to the OSS library

Bug Fixes

by mad\tlwilmar at April 13, 2015 09:24 PM

LLVM Blog

LLVM Weekly - #67, Apr 13th 2015

Welcome to the sixty-seventh 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

EuroLLVM is going on today and tomorrow in London. I hope to see a number of you there. Provided there's a reasonable internet connection, I hope to be live-blogging the event on the llvmweekly.org version of this issue.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

A new post on the LLVM Blog deatils how to use LLVM's libFuzzer for guided fuzzing of libraries.

The Red Hat developer blog has an article about libgccjit, a new feature in GCC5, which may be of interest.

On the mailing lists

LLVM commits

  • The R600 backend gained an experimental integrated assembler. r234381.

  • The libFuzzer documentation has been extended to demonstrate how the Heartbleed vulnerability could have been found using it. r234391.

  • The preserve-use-list-order flags are now on by default. r234510.

  • LLVM gained a pass to estimate when branches in a GPU program can diverge. r234567.

  • The ARM backend learnt to recognise the Cortex-R4 processor. r234486.

Clang commits

  • Lifetime markers for named temporaries are now always inserted. r234581.

  • The quality of error messages for assignments to read-only variables has been enhanced. r234677.

  • clang-format's nested block formatting got a little better. r234304.

Other project commits

  • Support for the 'native' file format was removed from lld. r234641.

  • Remote debugging, the remote test suite, and the process to cross-compile lldb has been documented. r234317, r234395, r234489.

  • LLDB gained initial runtime support for RenderScript. r234503.

by Alex Bradbury (noreply@blogger.com) at April 13, 2015 12:25 PM

April 09, 2015

LLVM Blog

Simple guided fuzzing for libraries using LLVM's new libFuzzer


Fuzzing (or fuzz testing) is becoming increasingly popular. Fuzzing Clang and fuzzing with Clang is not new: Clang-based AddressSanitizer has been used for fuzz-testing the Chrome browser for several years and Clang itself has been extensively fuzzed using csmith and, more recently, using AFL. Now we’ve closed the loop and started to fuzz parts of LLVM (including Clang) using LLVM itself.

LibFuzzer, recently added to the LLVM tree, is a library for in-process fuzzing that uses Sanitizer Coverage instrumentation to guide test generation. With LibFuzzer one can implement a guided fuzzer for some library by writing one simple function: 
extern "C" void TestOneInput(const uint8_t *Data, size_t Size);

We have implemented two fuzzers on top of LibFuzzer: clang-format-fuzzer and clang-fuzzer. Clang-format is mostly a lexical analyzer, so giving it random bytes to format worked perfectly and discovered over 20 bugs. Clang however is more than just a lexer and giving it random bytes barely scratches the surface, so in addition to testing with random bytes we also fuzzed Clang in token-aware mode. Both modes found bugs; some of them were previously detected by AFL, some others were not: we’ve run this fuzzer with AddressSanitizer and some of the bugs are not easily discoverable without it.

Just to give you the feeling, here are some of the input samples discovered by the token-aware clang-fuzzer starting from an empty test corpus:
 static void g(){}
 signed*Qwchar_t;
 overridedouble++!=~;inline-=}y=^bitand{;*=or;goto*&&k}==n
 int XS/=~char16_t&s<=const_cast<Xchar*>(thread_local3+=char32_t

Fuzzing is not a one-off thing -- it shines when used continuously. We have set up a public build bot that runs clang-fuzzer and clang-format-fuzzer 24/7. This way, the fuzzers keep improving the test corpus and will periodically find old bugs or fresh regressions (the bot has caught at least one such regression already).

The benefit of in-process fuzzing compared to out-of-process is that you can test more inputs per second. This is also a weakness: you can not effectively limit the execution time for every input. If some of the inputs trigger superlinear behavior, it may slow down or paralyze the fuzzing. Our fuzzing bot was nearly dead after it discovered exponential parsing time in clang-format. You can workaround the problem by setting a timeout for the fuzzer, but it’s always better to fix superlinear behavior.

It would be interesting to fuzz other parts of LLVM, but a requirement for in-process fuzzing is that the library does not crash on invalid inputs. This holds for clang and clang-format, but not for, e.g., the LLVM bitcode reader.

Help is more than welcome! You can start by fixing one of the existing bugs in clang or clang-format (see PR23057, PR23052 and the results from AFL) or write your own fuzzer for some other part of LLVM or profile one of the existing fuzzers and try to make it faster by fixing performance bugs.

Of course, LibFuzzer can be used to test things outside of the LLVM project. As an example, and following Hanno Böck’s blog post on Heartbleed, we’ve applied LibFuzzer to openssl and found Heartbleed in less than a minute. Also, quite a few new bugs have been discovered in PCRE2 (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11), Glibc and MUSL libc (1, 2) .

Fuzz testing, especially coverage-directed and sanitizer-aided fuzz testing, should directly compliment unit testing, integration testing, and system functional testing. We encourage everyone to start actively fuzz testing their interfaces, especially those with even a small chance of being subject to attacker-controlled inputs. We hope the LLVM fuzzing library helps you start leveraging our tools to better test your code, and let us know about any truly exciting bugs they help you find!

by Kostya Serebryany (noreply@blogger.com) at April 09, 2015 09:06 PM

April 06, 2015

LLVM Blog

LLVM Weekly - #66, Apr 6th 2015

Welcome to the sixty-sixth 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

color_coded, a vim plugin for syntax highlighting using libclang is now available.

Ravi, a dialect of Lua with JIT compilation via LLVM has has its first alpha release. The status of JIT compilation can be seen here.

On the mailing lists

LLVM commits

  • API migration has started for GEP constant factories. For now, nullptr can be passed for the pointee type, but you'll need to pass the type explicitly to be future-proof. r233938.

  • A proof of concept fuzzer based on DataFlowSanitizer has been added, as well as support for token-based fuzzing. r233613, r233745.

  • DebugLoc's API has been rewritten. r233573.

  • The SystemZ backend now supports transactional execution on the zEC12. r233803.

Clang commits

  • Clang gained a toolchain driver for targeting NaCl. r233594.

  • The size of various Stmt subclasses has been optimised on 64-bit targets. r233921.

  • Codegen was added for the OpenMP atomic update construct. r233513.

Other project commits

  • LLDB system initialization has been reworked. r233758.

by Alex Bradbury (noreply@blogger.com) at April 06, 2015 09:57 AM

March 30, 2015

LLVM Blog

LLVM Weekly - #65, Mar 30th 2015

Welcome to the sixty-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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

The Z3 theorem prover from Microsoft Research is now on Github, and more importantly now released under the MIT license. This is a true open source license allowing commercial use, unlike the previous non-commercial use only license. It's been used with LLVM in the ALIVe project.

The schedule for EuroLLVM has been published. There are still a number of early registration tickets left. If you can be in London on 13th and 14th of April then I'd highly recommend registering.

On the mailing lists

LLVM commits

  • The GlobalMerge pass will no longer run at O1 on AArch64+ARM, and instead will only be enabled at O3. r233024.

  • A float2int pass was added which, as the name suggests, attempts to demote from float to int where possible. r233062.

  • A simple Orc-based lazy JIT has been added to lli. r233182.

  • LLVM gained support for PowerPC hardware transactional memory. r233204.

  • The ARMv8.1a architecture has been added along with some of its new instructions. r233290, r233301

Clang commits

  • The on-disk hash table for modules should now have a stable representation. r233156, r233249.

  • Intrinsics have been added for PowerPC hardware transaction memory support. r233205.

  • An initial version of a clang-fuzzer has been added, making use of the LLVMFuzzer library. r233455.

Other project commits

  • libclc gained more builtin implementations. r232977, r232965, r232964.

  • lld learnt how to understand the MIPS N64 relocation record format (which is described in the commit message). r233057.

  • lld's ARM support has improved with with the addition of indirect function handling and GOT relocations. r233383, r233277.

by Alex Bradbury (noreply@blogger.com) at March 30, 2015 12:40 PM

March 23, 2015

LLVM Blog

LLVM Weekly - #64, Mar 23rd 2015

Welcome to the sixty-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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Students have until Friday 27th March to get their applications in for Google Summer of Code. This gives the opportunity to get paid $5500 to work on open source over the summer, under the mentorship of someone from the community. See here for the list of mentoring organisations advertising LLVM-related projects. Please do help spread the word. I am biased, but I'd like to draw particular attention to the wide variety of lowRISC GSoC ideas, including a project to implement an LLVM pass using tagged memory to provide protection against control-flow hijacking.

GCC 5 is starting to get near to release. The first release candidate is expected in the first week of April.

On the mailing lists

LLVM commits

  • The backend for the Hexagon DSP has continued to grow over the past few weeks. Most recently, support for vector instructions has been added. r232728.

  • The LLVM developer documentation grew guidance on writing commit messages. r232334.

  • LLVM learnt to support the ARMv6k target. The commit message has a handy ascii art diagram to explain its position in the ARM family. r232468.

Clang commits

  • The size of a Release+Asserts clang binary has been reduced by ~400k by devirtualising Attr and its subclasses. r232726.

  • Work on MS ABI continues, with support for HandlerMap entries for C++ catch. r232538.

  • A new warning, -Wpartial-ability will warn when using decls that are not available on all deployment targets. r232750.

  • C++14 sized deallocation has been disabled default due to compatibility issues. r232788.

Other project commits

  • Performance of a self-hosted lld link has again been improved. It's now down to 3 seconds on the patch author's machine (vs 5 seconds before, and 8 seconds for the GNU BFD linker). r232460.

  • libcxx gained the <experimental/tuple> header which implements most of the tuple functionality specified in the library fundamentals TS. r232515.

  • LLD now supports the semantics of simple sections mappings in linker scripts and can handle symbols defined in them. r232402, r232409.

  • Mips64 lldb gained an initial assembly profiler. r232619.

by Alex Bradbury (noreply@blogger.com) at March 23, 2015 03:09 PM

March 16, 2015

OpenMP Runtime Project

New code release

We are excited to announce the next release of the Intel® OpenMP* Runtime Library at openmprtl.org. This release aligns with Intel® Parallel Studio XE 2015 Composer Edition Update 3.

New Features

  • OpenMP* 4.1: Support for a new kind of task needed for asynchronous offload
  • Improved Intel® Trace Analyzer and Collector and Intel® VTune™ Performance Tools support

Bug Fixes

by mad\tlwilmar at March 16, 2015 06:32 PM

LLVM Blog

LLVM Weekly - #63, Mar 16th 2015

Welcome to the sixty-third 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

LLVM is taking part in Google Summer of Code as a mentoring organisation. Students can earn a $5500 stipend by working on open source projects over the summer, and applications upon today (March 16th). See here for the list of mentoring organisations advertising LLVM-related projects. Please do help spread the word. I am biased, but I'd like to draw particular attention to the wide variety of lowRISC GSoC ideas, including a project to implement an LLVM pass using tagged memory to provide protection against control-flow hijacking.

Version 0.11 of Pocl, the portable open-source OpenCL implementation has been released. Additions in this release include initial Android support and MIPS architecture support.

Version 1.11 of TCE, the TTA-based (Transport Triggered Architecture) Co-design Environment, which uses LLVM has been released. This release adds support for LLVM 3.6.

There will be a LLVM microconference at the Linux Plumbers Conference in August. There is a call for speakers.

On the mailing lists

LLVM commits

  • As DataLayout is now mandatory, LLVM APIs have been updated to use references to DataLayout. r231740.

  • Support was added for part-word atomics on PowerPC. r231843.

  • Initial work on enhancing ValueTracking to infer known bits of a value from known-true conditional expressions has landed. r231879.

  • The PowerPC READMEs have been updated to list potential future enhancements. r231946.

  • The llvm.eh.actions intrinsic has been added. r232003.

  • The documentation for llvm-cov has been updated. r232007.

  • The getting started docs now describe CMake as the preferred way to build LLVM. r232135.

  • llvm-vtabledump is now known as llvm-cxxdump. r232301.

Clang commits

  • The steady stream of OpenMP patches continues, with the addition of codegen support for the omp task directive and omp for. r231762, r232036.

  • Copy-constructor closures for MS ABI support has been added. r231952.

Other project commits

  • LLD gained support for linker script expression evaluation and parsing of the MEMORY and EXTERN commands. r231707, r231928, r232110.

  • LLDB gained a CODE_OWNERS.txt file. r231936.

by Alex Bradbury (noreply@blogger.com) at March 16, 2015 03:35 PM

March 09, 2015

LLVM Blog

LLVM Weekly - #62, Mar 9th 2015

Welcome to the sixty-second 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

LLVM is taking part in Google Summer of Code as a mentoring organisation. Students can earn a $5500 stipend by working on open source projects over the summer. See here for the list of mentoring organisations advertising LLVM-related projects. Please do help spread the word, applications open on Monday the 16th of March. I am biased, but I'd like to draw particular attention to the wide variety of lowRISC GSoC ideas, including a project to use tagged memory to provide protection against control-flow hijacking.

Ravi, a programming language based on Lua 5.3 has been announced. It features JIT compilation using LLVM, though in the current development version only a fraction of the Lua bytecodes are JIT-compiled.

On the mailing lists

LLVM commits

  • An initial implementation of a loop interchange pass has landed. This will interchange loops to provide a more cache-friendly memory access. r231458.

  • A high-level support library for the new pass manager has been added. r231556.

  • The LLVM performance tips document has seen some new additions. r230995, r231352.

  • DenseMapIterators will now fail fast when compiled in debug mode. r231035.

  • LowerBitSets will now use byte arrays rather than bit sets to represent in-memory bit sets, which can be looked up with only a few instructions. r231043.

  • Another large portion of the DebugInfo changes has landed. r231082.

  • A new optimisation for AddressSanitizer has been added that reduces the amount of instrumentation needed, eliminating it when accessing stack variables that can be proven to be inbounds. r231241.

  • llvm.frameallocate has been replaced with llvm.frameescape. r231386.

Clang commits

  • When the -pedantic flag is given, clang will warn when a format string uses %p with non-void* args. r231211.

  • Work on MS ABI support continues. Throwing a C++ exception under the MS ABI is now supported. r231328.

Other project commits

  • The lld resolver has had a significant performance optimisation. The commit message indicates linking chrome.dll now takes 30 seconds down from 70 seconds. r231434.

  • The static binary size of lldb-server has been reduced due to a reduction in the number of initialised components. r230963.

by Alex Bradbury (noreply@blogger.com) at March 09, 2015 10:36 AM

March 02, 2015

LLVM Blog

LLVM Weekly - #61, Mar 2nd 2015

Welcome to the sixty-first 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

The biggest headline this week is undoubtedly the release of LLVM/Clang 3.6. See the LLVM 3.6 release notes and the Clang 3.6 release notes for a full run-down of the major changes.

The LLVMSharp C# and .NET bindings to LLVM have been released.

Pyston, the LLVM-based Python JIT developed by Dropbox has had its 0.3 release. It is now minimally self-hosting. You can also see performance results online.

Readers may enjoy this walkthrough of creating a basic compiler with LLVM.

On the mailing lists

LLVM commits

  • Work has started on the move towards opaque pointer types. See the commit messages for more details and help on migrating existing textual IR. r230786, r230794.

  • The PlaceSafepoints and RewriteGCForStatepoints passes have been documented. r230420.

  • The GC statepoints documentation has been cleaned up and extended with example IR, assembly, and stackmaps. r230601.

  • The loop-invariant code motion pass has been refactored to expose its core functionality as utility functions that other transformations could use. r230178.

  • Implementation of support for alloca on MIPS fast-isel has started. r230300.

  • The PowerPC backend gained support for the QPX vector instruction set. r230413.

  • InductiveRangeCheckElimination can now handle loops with decreasing induction variables. r230618.

  • Among other improvements, llvm-pdbdump gained colorized output. r230476.

  • The Forward Control Flow Integrity Pass has been removed as it is being rethought and is currently unused. r230780.

  • The Performance Tips for Frontend Authors document was born. r230807.

Clang commits

  • The control flow integrity design docs has been updated to document optimisations. r230458, r230588.

Other project commits

  • Remote testing support was added to the libc++ and libc++abi test suites. r230592, r230643.

  • LLD learned to understand .gnu.linkonce input sections. r230194.

by Alex Bradbury (noreply@blogger.com) at March 02, 2015 11:12 AM

February 27, 2015

LLVM Blog

LLVM 3.6 Release

LLVM 3.6 is now available!

Get it here: http://llvm.org/releases/

This release contains the work of the LLVM community over the past six months: many many bug fixes, optimization improvements, support for more proposed C++1z features in Clang, better native Windows compatibility, embedding LLVM IR in native object files, Go bindings, and more. For details, see the release notes [LLVM, Clang].

Many thanks to everyone who helped with testing, fixing, and getting the release into a good state!

Special thanks to the volunteer release builders and testers, without whom this release would not be possible: Dimitry Andric, Sebastian Dreßler, Renato Golin, Sylvestre Ledru, Ben Pope, Daniel Sanders, and Nikola Smiljanić!

If you have any questions or comments about this release, please contact the community on the mailing lists. Onwards to 3.7!

by Hans Wennborg (noreply@blogger.com) at February 27, 2015 08:48 PM

February 23, 2015

LLVM Blog

LLVM Weekly - #60, Feb 23rd 2015

Welcome to the sixtieth 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

LLVM/Clang 3.6.0-rc4 is now available for testing.

A new LLVM-based tainted flow analysis tool has been created. It's a tool designed to help detect timing attack vulnerabilities. An online demo is available.

The March bay-area LLVM social will take place on Thursday 5th March, along with the Game Developer's Conference.

The Cambridge LLVM social will take place on Wednesday 25th Feb.

HHVM, the optimised PHP virtual machine from Facebook plan to integrate an LLVM-based optimisation phase.

On the mailing lists

LLVM commits

  • The coding standards document has been updated now that MSVC 2012 support has been dropped. r229369.

  • The Orc API continues to evolve. The JITCompileCallbackManager has been added to create and manage JIT callbacks. r229461.

  • A new pass, the bit-tracking dead code elimination pass has been added. It tracks dead bits of integer-valued instructions and removes them when all bits are set. r229462.

  • The SystemZ backend now supports all TLS access models. r229652, r229654.

  • A new pass for constructing gc.statepoint sequences with explicit relocations was added. The pass will be further developed and bugfixed in-tree. r229945.

  • The old x86 vector shuffle lowering code has been removed (the new shuffle lowering code has been the default for ages and known regressions have been fixed). r229964.

  • A new bitset metadata format and lowering pass has been added. In the future, this will be used to allow a C++ program to efficiently verify that a vtable pointer is in the set of valid vtable pointers for the class or its derived classes. r230054.

Clang commits

  • clang-format gained support for JS type annotations and classes. r229700, r229701.

  • Most of the InstrProf coverage mapping generation code has been rewritten. r229748.

  • Clang learnt how to analyze FreeBSD kernel printf extensions. r229921.

  • Support has been added to Clang for a form of Control Flow Integrity for virtual function calls. It verifies the vptr of the correct dynamic type is being used. r230055.

Other project commits

  • ThreadSanitizer gained support for MIPS64. r229972.

  • lldb now supports process language on Android from lldb-gdbserver. r229371.

  • OpenMP gained a new user-guided lock API. r230030.

by Alex Bradbury (noreply@blogger.com) at February 23, 2015 11:05 AM

February 16, 2015

LLVM Blog

LLVM Weekly - #59, Feb 16th 2015

Welcome to the fifty-ninth 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Reminder, the EuroLLVM 2015 call for papers submission deadline is TODAY. See here for details.

LLVM and Clang 3.6-rc3 has been tagged, any help with testing is greatly appreciated.

On the mailing lists

LLVM commits

  • The biggest chunk of internal refactoring of debug metadata has landed, with the addition of specialized debug info metadata nodes. r228640.

  • New intrinsics llvm.eh.begincatch and llvm.eh.endcatch intrinsics have been added to support Windows exception handling. r228733.

  • A DebugInfoPDB implementation using the MS Debug Interface Access SDK has landed. r228747.

  • SimplifyCFG will now use TargetTransformInfo for cost analysis. r228826.

  • A profitability heuristic has been added for the x86 mov-to-push optimisation. r228915.

  • PassManager.h is now LegacyPassManager.h. As described in the commit message, if you are an out of tree LLVM user you may need to update your includes. r229094.

Clang commits

  • The /volatile:ms semantics have been implemented, turning volatile loads and stores into atomic acquire and release operations. r229082.

Other project commits

  • C++14's sized deallocation functions have been implemented in libcxx. r229281.

  • lld learnt to handle the --wrap option. r228906.

  • lldb gained the concept of "runtime support values". r228791.

  • The remote-android platform has been added to lldb. r228943.

by Alex Bradbury (noreply@blogger.com) at February 16, 2015 11:15 AM

February 09, 2015

LLVM Blog

LLVM Weekly - #58, Feb 9th 2015

Welcome to the fifty-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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

The Red Hat developer blog has a post about the plan to change the G++ ABI along with GCC 5. This is required for full C++11 compatibility. Unlike the last ABI change where the libstdc++ soname was changed, it will stay the same and instead different mangled names will be used for symbols.

Quarks lab have a tutorial on how to add a simple obfuscation pass to LLVM.

On the mailing lists

LLVM commits

  • A straight-line strength reduction pass has been introduced. This is intended to simplify statements that are generated after loop unrolling. It is enabled only for NVPTX for the time being. r228016.

  • A MachineInstruction pass that converts stack-relative moves of function arguments to use the X86 push instruction. This is only enabled when optimising for code size. r227752.

  • The BasicAA will now try to disambiguate GetElementPtr through arrays of structs into different fields. r228498.

  • Work on improving support in LLVM for GC continues, with the addition of a pass for inserting safepoints into arbitrary IR. r228090.

  • (Very) minimal support for the newly announced ARM Cortex-A72 landed. For now, the A72 is modeled as an A57. r228140.

  • A new heuristic has been added for complete loop unrolling, which looks at what loads might be made constant if the loop is completely unrolled. r228265.

  • A pass to exploit PowerPC's pre-increment load/store support has been added. r228328.

  • A platform-independent interface to a PDB reader has landed. r228428.

  • LLVM learnt to recognise masked gather and scatter intrinsics. r228521.

Clang commits

  • Clang learnt the 'novtable' attribute (for MS ABI support). r227796, r227838.

  • New functionality has been added for thread safety analysis, before/after annotations can now be used on mutexes. r227997.

Other project commits

  • A whole bunch of work on LLDB with multithreaded applications on Linux has landed. r227909, r227912, r227913, and more.

  • The default Polly build is now completely free of GPL dependencies. The isl and imath dependencies have been imported into the codebase to make it easier to build with a known-good revision. r228193.

by Alex Bradbury (noreply@blogger.com) at February 09, 2015 05:17 PM

February 02, 2015

LLVM Blog

LLVM Weekly - #57, Feb 2nd 2015

Welcome to the fifty-seventh 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

I've been at FOSDEM this weekend in Brussels (which is why this week's issue is perhaps a little shorter than usual!). Most talks were recorded and I'll be linking to the videos from the LLVM devroom once they're up. For those interested, you can see the slides from my lowRISC talk here. If you want to chat about the project, you may want to join #lowRISC on irc.oftc.net.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Eli Bendersky has written a useful introduction to using the llvmlite Python to LLVM binding, which was borne out of the Numba project.

LLVM/Clang 3.6-rc2 has been tagged and is ready for testing.

The next LLVM bay-area social is taking place on Feb 5th at 7pm.

The EuroLLVM call for papers closes on Feb 16th.

On the mailing lists

LLVM commits

  • A simple in-process fuzzer was added to LLVM. r227252.

  • The programmer's manual gained a section about type hierarchies, polymorphism, and virtual dispatch. r227292.

  • The upstreaming of Sony's patches for their PS4 compiler started with the addition of the PS4 target triple. r227060.

  • DataLayout now lives again in the TargetMachine rather than the TargetSubtagertInfo. r227113.

  • RuntimeDyld learned to support weak symbols. r227228.

  • LLVM gained a new tool, llvm-pdbdump to dump the contents of Microsoft PDB ('Program DataBase') files, including debug tables. r227241, r227257.

  • The loop vectorizer now supports an arbitrary constant step for its induction variables, rather than just -1 or +1. r227557.

Clang commits

  • The clang-format-fuzzer tool was added, which builds on the LLVM fuzzer lib. r227354.

  • MS ABI work continues with proper support for setjmp. r227426.

  • Clang started to learn about the PS4 target triple. r227194.

Other project commits

  • The PowerPC ELF target was dropped from lld. r227320.

by Alex Bradbury (noreply@blogger.com) at February 02, 2015 01:52 PM

January 29, 2015

Aaron Ballman

Reference Data Members and const Objects

Why is the following C++ code well-formed?

class C {
  int &ref;

public:
  C(int &i) : ref(i) {}

  int& get_ref() { return ref; }

  void f(int i) const {
    ref = i;
  }
};

(If you’re not certain what I’m talking about, notice that f() is declared as a const member function, and yet it mutates the class data member ref.)

A const member function is a design contract guaranteeing the caller that this function will not mutate the object’s internal state in any observable way. In the example above, ref can be observed because of the get_ref() call, which may lead you to believe this is some sort of bug with the compiler or with C++ itself, or perhaps is undefined behavior. However, this code is well-formed, and is a conscious design of the language that makes sense when you think more deeply about what a reference is.

References are not like pointers, or other objects, in that they only exist to refer to another object. In the case of a reference data member of a class, that means the reference must be initialized by the class constructor, and so its referent exists outside of the class itself (in a sane universe). When you mutate a reference member of a class, you are not mutating the internal state of the class — you are mutating something external to the class. For this reason, reference data members of a class may be mutated with a const context. This holds true even when the actual object is const, not just the member function. For instance:

struct C {
  int &ref;

  C(int &i) : ref(i) {}
};

void f() {
  int i = 12;
  const C c(i);
  c.ref = 100;    
}

This isn’t something that’s widely used, but it is something to understand from a design principle perspective.

by Aaron Ballman at January 29, 2015 06:25 PM

January 26, 2015

LLVM Blog

LLVM Weekly - #56, Jan 26th 2015

Welcome to the fifty-sixth 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. 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@asbradbury.org, or or @llvmweekly or @asbradbury on Twitter.

I'll be talking the lowRISC project to produce a fully open-source SoC at FOSDEM this coming weekend. Do come and see my main track talk and read my speaker interview for more background. There is of course an LLVM toolchain devroomon the Sunday.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Stephen Diehl has written an absolutely fantastic tutorial on writing an LLVM specializer for Python, guiding you through the process of creating something like Numba.

A new tool, Dwgrep (DWARF Grep) may be of interest to many LLVM Weekly readers. This blog post gives an intro to using it.

Paul Smith has a blog post on getting started with the LLVM C API.

A post on the official LLVM Blog announces that LLDB is coming to Windows, announcing to a wider audience that it is now possible to debug simple programs with LLDB on Windows and giving a rationale for investing effort into porting LLDB to Windows and adding support for the MS debug format. The post also features a todo list indicating what's next for Windows support.

A draft version 0.1 of the IA-32 psABI (processor specific application binary interface) is available. This aims to supplement the existing System V ABI with conventions relevant to newer features such as SSE1-4 and AVX. Comments are welcome.

LLVM/Clang 3.6-rc1 is now available. Get testing and filing bugs.

ELLCC 0.1.8 has been released. ELLCC is an LLVM/Clang-based cross compilation toolchain.

LLDB now has it's own IRC channel. You'll want to join #lldb on irc.oftc.net.

On the mailing lists

LLVM commits

  • A backend targeting the extended BPF (Berkeley Packet Filter) interpreter/JIT in the Linux kernel has been added. See this LWN article for more background. r227008.

  • The initial version of the new ORC JIT API has landed. r226940.

  • There's been a flurry of work on the new pass manager this week. One commit I will choose to pick out is the port of InstCombine to the new pass manager, which seems like a milestone or sorts. r226987.

  • LLVM learnt how to use the GHC calling convention on AArch64. r226473.

  • InstCombine will now canonicalize loads which are only ever stored to always use a legal integer type if one is available. r226781.

  • The llvm_any_ty type for intrinsics has been born. r226857.

  • llvm-objdump now understands -indirect-symbols to dump the Mach-O indirect symbol table. r226848.

Clang commits

  • Clang now supports SPIR calling conventions. r226548.

  • It's now possible to set the stack probe size on the command line. r226601.

  • Clang gained initial support for Win64 SEH IR emission. r226760.

Other project commits

  • Sun Solaris users, now is the time to celebrate. libc++ will now build on your platform of choice. r226947.

  • A minimal implementation of ARM static linking landed in lld. r226643.

  • Basic support for PPC was added to openmp. r226479.

by Alex Bradbury (noreply@blogger.com) at January 26, 2015 02:56 PM

January 20, 2015

LLVM Blog

LLDB is Coming to Windows

We've spoken in the past about teaching Clang to fully support Windows and be compatible with MSVC.  Until now, a big missing piece in this story has been debugging the clang-generated executables.  Over the past 6 months, we've started working on making LLDB work well on Windows and support debugging both regular Windows programs and those produced by Clang.

Why not use an existing debugger such as GDB, Visual Studio's, or WinDBG?  There are a lot of factors in making this kind of decision.  For example, while GDB understands the DWARF debug information produced by Clang on Windows, it doesn't understand the Microsoft C++ ABI or debug information format.  On the other hand, neither Visual Studio nor WinDBG understand the DWARF debug information produced by Clang.  With LLDB, we can teach it to support both of these formats, making it usable with a wider range of programs.  There are also other reasons why we're really excited to work on LLDB for Windows, such as the tight integration with Clang which lets it support all of the same C++ features in its expression parser that Clang supports in your source code.  We're also looking to continue adding new functionality to the debugging experience going forward, and having an open source debugger that is part of the larger LLVM project makes this really easy.

The past few months have been spent porting LLDB's core codebase to Windows.  We've been fixing POSIX assumptions, enhancing the OS abstraction layer, and removing platform specific system calls from generic code.  Sometimes we have needed to take on significant refactorings to build abstractions where they are necessary to support platform specific differences.  We have also worked to port the test infrastructure to Windows and set up build bots to ensure things stay green.

This preliminary bootstraping work is mostly complete, and you can use LLDB to debug simple executables generated with Clang on Windows today.  Note the use of the word "simple".  At last check, approximately 50% of LLDB's tests fail on Windows.  Our baseline, however, which is a single 32-bit executable (i.e. no shared libraries), single-threaded application built and linked with Clang and LLD using DWARF debug information, works today.  We've tested all of the fundamental functionality such as:
  1. Various methods of setting breakpoints (address, source file+line, symbol name, etc)
  2. Stopping at and continuing from breakpoints
  3. Process inspection while stopped, such as stack unwinding, frame setting, memory examination, local variables, expression evaluation, stepping, etc  (one notable exception to this is that step-over doesn't yet work well in the presence of limited symbol information).
Of course, there is still more to be done.  Here are some of the areas we're planning to work on next:
  1. Fixing low hanging fruit by improving the pass-rate of the test suite.
  2. Better support for debugging multi-threaded applications.
  3. Support for debugging crash dumps.
  4. Support for debugging x64 binaries.
  5. Enabling stepping through shared libraries.
  6. Understanding PDB (for debugging system libraries, and executables generated with MSVC).  Although the exact format of PDB is undocumented, Microsoft still provides a rich API for querying PDB in the form of the DIA SDK.
  7. Adding debugging commands familiar to users of WinDBG (e.g. !handle, !peb, etc)
  8. Remote debugging
  9. Symbol server support
  10. Visual Studio integration
If you're using Clang on Windows, we would encourage you to build LLDB (it should be in the Windows LLVM installer soon) and let us know your thoughts by posting them to lldb-dev.  Make sure you file bugs against LLDB if you notice anything wrong, and we would love for you to dive into the code and help out.  If you see something wrong, dig in and try to fix it, and post your patch to lldb-commits.

by Zachary Turner (noreply@blogger.com) at January 20, 2015 07:29 PM

January 19, 2015

LLVM Blog

LLVM Weekly - #55, Jan 19th 2015

Welcome to the fifty-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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

It seems to have been a very busy week in the world of LLVM, particularly with regards to discussion on the mailing list. Due to travel etc and the volume of traffic, I haven't been able to do much summarisation of mailing list discussion I'm afraid.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

LLM/Clang 3.6 has been branched and subsequently, 3.6 RC1 has been tagged.

LLVM/Clang 3.5.1 seems to have been quietly released.

Registration for EuroLLVM 2015, to be held at Goldsmiths College in London, UK on April 13-14th is now open.

All slides and videos from the last LLVM Developers' meeting are now live, including those from Apple employees.

On the mailing lists

LLVM commits

  • A new code diversity feature is now available. The NoopInsertion pass will add random no-ops to x86 binaries to try to make ROP attacks more difficult by increasing diversity. r225908. I highly recommend reading up on the blind ROP attack published last year. It would also be interesting to see an implementation of G-Free for producing binaries without simple gadgets. The commit was later reverted for some reason.

  • A nice summary of recent MIPS and PowerPC target developments, as well as the OCaml bindings is now there in the form of the 3.6 release notes. r225607, r225695, r225779.

  • LLVM learned the llvm.frameallocate and llvm.framerecover intrinsics, which allow multiple functions to share a single stack allocation from one function's call frame. r225746, r225752.

  • An experimental (disabled by default) 'inductive range check elimination' pass has landed. This attempts to eliminates range checks of the form 0 <= A*I + B < Length. r226201.

  • StackMap/PatchPoint support is now available for the PowerPC target. r225808.

  • Initial support for Win64 SEH catch handlers has landed. See the commit message for current missing functionality. r225904.

  • A new utility script has been started to help update simple regression tests. It needs some work to generalise it beyond x86. r225618.

  • TargetLibraryInfo has been moved into the Analysis library. r226078.

Clang commits

  • The new -fno-inline-asm flag has been added to disallow all inline asm. If it exists in the input code it will be reported as an error.
    r226340.

  • -fsanitize-recover command line flags are again supported. r225719.

  • The integrated assembler is now used by default on 32-bit PowerPC and SPARC. r225958.

Other project commits

  • The libcxx build system learnt how to cross-compile. r226237.

  • LLD gained a nice speedup by speculative instantiating archive file members. This shaves off a second or two for linking lld with lld. r226336.

  • LLD learnt the --as-needed flag (previously this was the default behaviour). r226274.

  • OpenMP gained an AARch64 port. r225792.

by Alex Bradbury (noreply@blogger.com) at January 19, 2015 05:58 PM

January 13, 2015

LLVM Blog

LLVM Weekly - #54, Jan 12th 2015

Welcome to the fifty-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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

As you receive this week's issue, I should be on my way to California where I'll be presenting lowRISC at the RISC-V workshop in Monterey and having a few mother meetings. I'm in SF Fri-Sun and somewhat free on the Saturday if anyone wants to meet and chat LLVM or lowRISC/RISC-V.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Euro LLVM 2015 will be held on April 13th-14th in London, UK. The call for papers is now open with a deadline of 16th Feb.

Talks for the LLVM devroom at FOSDEMhave been announced. The LLVM devroom is on Sunday 1st Feb. Readers will be pleased to know this doesn't clash with my talk on lowRISC which is on the Saturday.

Google now use Clang for production Chrome builds on Linux. They were previously using GCC 4.6. Compared to that baseline, performance stayed roughly the same while binary size decreased by 8%. It would certainly have been interesting to compare to a more recent GCC baseline. The blog post indicates they're hopeful to use Clang in the future for building Chrome for Windows.

Philip Reames did an interesting back of the envelope calculation about the cost of maintaining LLVM. He picked out commits which seems like they could be trivially automated and guesstimated a cost based on developer time. The figure he arrives at is $1400 per month.

The next LLVM social for Cambridge, UK will be on Wed 21st Jan at 7:30pm.

On the mailing lists

LLVM commits

  • An option hoist-cheap-insts has been added to the machine loop invariant code motion pass to enable hosting even cheap instructions (as long as register pressure is low). This is disabled by default. r225470.

  • The calculation of the unrolled loop size has been fixed. Targets may want to re-tune their default threshold. r225565, r225566.

  • DIE.h (datastructures for DWARF info entries) is now a public CodeGen header rather than being private to the AsmPrinter implementation. dsymutil will make use of it. r225208.

  • The new pass manager now has a handy utility for generating a no-op pass that forces a usually lazy analysis to be run. r225236.

  • There's been a minor change to the .ll syntax for comdats. r225302.

  • There have been some minor improvements to the emacs packages for LLVM and tablegen mode. r225356.

  • An example GCStrategy using the new statepoint infrastructure has been added. r225365, r225366.

Clang commits

  • A Wself-move warning has been introduced. Similar to -Wself-assign, it will warn you when your code tries to move a value to itself. r225581.

  • The I, J, K, M, N, O inline assembly constraints are now checked. r225244.

Other project commits

  • The libcxx test infrastructure has been refactored into separate modules. r225532.

  • The effort to retire InputElement in lld continues. Linker script files are no longer represented as an InputElement. r225330.

  • Polly has gained a changelog in preparation of the next release.r225264.

  • Polly has also gained a TODO list for its next phase of development. r225388.

by Alex Bradbury (noreply@blogger.com) at January 13, 2015 02:10 AM

January 11, 2015

Philip Reames

How much does it cost to maintain LLVM?

In early October of 2014, I started collecting changes that I saw fly by on llvm-commits that I thought would be straight-forward to automate.  I was trying to be pretty conservative, so these tend to be pretty basic things: fixing deceptive white space around an if clause, removing the name of a method from it’s doxygen comment, removing a couple of syntactically redundant semi colons, and things of similar complexity.  These weren’t chosen because they were interesting, but precisely because they were not.

In the 66 days since I started collecting, I’ve saved 105 unique commits.  That’s a bit less than 2 per day, and only about 1.6% of the 6,500 commits made to LLVM in that time.

Let’s assume that each of those changes took an average of 15 minutes on the part of their author.  That’s not too much more than a single build and test cycle, so it seems like a reasonable estimate.  At roughly $2 per developer minute, we can guesstimate that each of these changes cost about $30.  Taken together, these 105 changes consumed about 26 hours of developer time at a cost of a bit over $3,150.

This gives us a value for straight forward code maintenance activities of roughly $1,400 per month (or roughly $50 per day.)

If anything, this is an extremely low estimate.  I know several of these changes required review, and at least a couple of them broke the build and had to be reverted.  We could probably add in several more hours of developer time just for that alone.

Now this is only a small fraction of the roughly $88,000 in development time going to the project as a whole each month*, but it’s still pretty material.

* Using the same logic as above: 15 minutes per change, $2 per developer minute, 6500 changes, llvm repository only.  It goes without saying that this is a massive understatement of the actual value of the contributed work.

by reames at January 11, 2015 04:54 AM

January 06, 2015

LLVM Blog

Using clang for Chrome production builds on Linux

Chrome 38 was released early October 2014. It is the first release where the Linux binaries shipped to users are built by clang. Previously, this was done by gcc 4.6. As you can read in the announcement email, the switch happened without many issues. Performance stayed roughly the same, binary size decreased by about 8%. In this post I'd like to discuss the motivation for this switch.

Motivation

There are two reasons for the switch.

1. Many Chromium developers already used clang on Linux. We've supported opting in to clang for since before clang supported C++ – because of this, we have a process in place for shipping new clang binaries to all developers and bots every few weeks. Because of clang's good diagnostics (some of which we added due to bugs in Chromium we thought the compiler should catch), speed, and because of our Chromium-specific clang plugin, many Chromium developers switched to clang over the years. Making clang the default compiler removes a stumbling block for people new to the project.

2. We want to use modern C++ features in Chromium. This requires a recent toolchain – we figured we needed at least gcc 4.8. For Chrome for Android and Chrome for Chrome OS, we updated our gcc compilers to 4.8 (and then 4.9) – easy since these ports use a non-system gcc already. Chrome for Mac has been using Chromium's clang since Chrome 15 and was already in a good state. Chrome for iOS uses Xcode 5's clang, which is also new enough. Chrome for Windows uses Visual Studio 2013 Update 4. On Linux, switching to clang was the easiest way forward.

Keeping up with C++'s evolution in a large, multi-platform project

C++ had been static for many years. C++11 is the first real update to the C++ language since the original C++ standard (approved on July 27 1998). C++98 predated the founding of Google, YouTube, Facebook, Twitter, the releases of Mac OS X and Windows XP, and x86 SSE instructions. The time between the two standards saw the rise and fall of the iPod, several waves of social networks, and the smartphone explosion.

The time between C++11 and C++14 was three years, and the next major iteration of the language is speculated to be finished in 2017, three years from C++14. This is a dramatic change, and it has repercussions on how to build and ship C++ programs. It took us 3+ years to get to a state where we can use C++11 in Chromium; C++14 will hopefully take us less long. (If you're targeting fewer platforms, you'll have an easier time.)

There are two parts to C++11: New language features, and new library features. The language features just require a modern compiler at build time on build machines, the library features need a new standard library at runtime on the user's machine.

Deploying a new compiler is conceptually relatively simple. If your developers are on Ubuntu LTS releases and you make them use the newest LTS release, they get new compilers every two years – so just using the default system compiler means you're up to two years behind. There needs to be some process to relatively transparently deploy new toolchains to your developers – an "evergreen compiler". We now have this in place for Chromium – on Linux, by using clang. (We still accept patches to keep Chromium buildable with gccs >= 4.8 for people who prefer compiling locally over using precompiled binaries, and we still use gcc as the target compiler for Chrome for Android and Chrome OS.)

The library situation is slightly more tricky: On Linux and Mac OS X, programs are usually linked against the system C++ library. Chrome wants to support Mac OS X 10.6 a bit longer (our users seem to love this OS X release), and the only C++ library this ships with is libstdc++ 4.2 – which doesn't have any C++11 bits. Similarly, Ubuntu Precise only has libstdc++ 4.6. It seems that with C++ updating more often, products will have to either stop supporting older OS versions (even if they still have many users on these old versions), adopt new C++ features very slowly, or ship with a bundled C++ standard library. The latter implies that system libraries shouldn't have a C++ interface for ABI reasons – luckily, this is mostly already the case.

To make things slightly more complicated, gcc and libstdc++ expect to be updated at the same time. gcc 4.8 links to libstdc++ 4.8, so upgrading gcc 4.8 while still linking to Precise's libstdc++ 4.6 isn't easy. clang explicitly supports building with older libstdc++ versions.

For Chromium, we opted to enable C++11 language features now, and then allow C++11 library features later once we have figured out the story there. This allows us to incrementally adopt C++11 features in Chromium, but it's not without risks: vector<int> v0{42} for example means something different with an old C++ library and a new C++ library that has a vector constructor taking an initializer_list. We disallow using uniform initialization for now because of this.

Since bundling a C++ library seems to become more common with this new C++ update cadence, it would be nice if compiler drivers helped with this. Just statically linking libstdc++ / libc++ isn't enough if you're shipping a product consisting of several executables or shared libraries – they need to dynamically link to a shared C++ library with the right rpaths, the C++ library probably needs mangled symbol names that don't conflict with the system C++ library which might be loaded into the same process due to other system libraries using it internally (for example, maybe using an inline namespace with an application-specific name), etc.

Future directions

As mentioned above, we're trying to figure out the C++ library situation. The tricky cases are Chrome for Android (which currently uses STLport) and Chrome for Mac. We're hoping to switch Chrome for Android to libc++ (while still using gcc as compiler). On Mac, we'll likely bundle libc++ with Chrome too.

We're working on making clang usable for compiling Chrome for Windows. The main motivations for this are using AddressSanitizer, providing a compiler with great diagnostics for developers, and getting our tooling infrastructure working on Windows (used for example automated large-scale cross-OS refactoring and for building our code search index – try clicking a few class names; at the moment only code built on Linux is hyperlinked). We won't use clang as a production compiler on Windows unless it produces a chrome binary that's competitive with Visual Studio's on both binary size and performance. (From an open-source perspective, it is nice being able to use an open-source compiler to compile an open-source program.)

You can reach us at clang@chromium.org

by thakis (noreply@blogger.com) at January 06, 2015 01:01 AM

January 05, 2015

LLVM Blog

LLVM Weekly - #53, Jan 5th 2015

Welcome to the fifty-third 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

I'm going to be in California next week for the RISC-V workshop. I'm arriving at SFO on Monday 12th and leaving on Sunday the 18th. Do let me know if you want to meet and talk lowRISC/RISC-V or LLVM, and we'll see what we can do.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

I was getting ready to break out gitstats for some analysis of the LLVM repo and I find to my delight that Phoronix has saved me the trouble and has shared some stats on activity in the LLVM repo over the past year.

Tom Stellard has made a blog post announcing some recent RadeonSI performance improvements on his LLVM development branch. This includes 60% improvement in one OpenCL benchmark and 10-25% in a range of other OpenCL tests.

Gaëtan Lehmann has written a blog post about getting started with libclang using the Python bindings.

The C++ Filesystem Technical Specification, based on the Boost.Filesystem library has been approved.

On the mailing lists

LLVM commits

  • Instruction selection for bit-permuting operations on PowerPC has been improved. r225056.

  • The scalar replacement of aggregates (SROA) pass has started to learn how to more intelligently handle split loads and stores. As explained in detail in the commit message, the old approach lead to complex IR that can be difficult for the optimizer to work with. SROA is now also more aggressive in its splitting of loads. r225061, r225074.

  • InstCombine will now try to transform A-B < 0 in to A < B. r225034.

  • The Hexagon (a Qualcomm DSP) backend has seen quite a lot of work recently. Interested parties are best of flicking through the commit log of lib/Target/Hexagon. r225005, r225006, etc.

Clang commits

Other project commits

by Alex Bradbury (noreply@blogger.com) at January 05, 2015 02:30 PM

December 29, 2014

LLVM Blog

LLVM Weekly - #52, Dec 29th 2014

Welcome to the fifty-second 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

This issue marks the end of one full year of LLVM Weekly. It's a little shorter than usual as the frenetic pace of LLVM/Clang development has slowed over the holiday period. Surprising even to me is that we managed to make it full all 52 weeks with an issue every Monday as promised. This requires a non-trivial amount of time each week (2-3+ hours), but I am intending to keep it going into 2015. I'd like to give a big thank you to everyone who's said hi at a conference, sent in corrections or tips on content, or just sent a random thank you. It's been very helpful in motivation. I don't currently intend to change anything about the structure or content of each issue for next year, but if you have any ideas then please let me know.

I can't make it to 31C3 due to the awkward timing of the event, but do let me know if there are any LLVM/Clang related talks worth sharing. There was a talk about Code Pointer Integrity which has previously been covered in LLVM Weekly and is working towards upstreaming. The video is here. If you're interested in lowRISC and at 31C3, Bunnie is leading a discussion about itat 2pm on Monday (today).

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

There doesn't seem to have been any LLVM or Clang related news over the past week. Everyone seems to be busy with non-LLVM related activities over the christmas break. If you're looking for a job though, Codeplay tell me they have two vancancies: one for a debugger engineer and another for a compiler engineer.

On the mailing lists

  • David Li has shared some early info on Google's plans for LTO. He describes the concept of 'peak optimization performance' and some of the objectives of the new design. This includes the ability to handle programs 10x or 100x the size of Firefox. We can expect more information in 2015, maybe as early as January.

  • The discussion on possible approaches to reducing the size of libLLVM has continued. Chris Bieneman has shared some more size stats. These gains come from removing unused intrinsics. Chandler Carruth has followed up with a pleasingly thought-provoking argument on a different approach: target-specific intrinsics shouldn't exist in the LLVM front or middle-end. He describes the obvious issues with this, with the most fiddly probably being instruction selection converting appropriate IR to the right target-specific functionality.

LLVM commits

  • The SROA (scalar replacement of aggregates) pass has seen some refactoring to, in the future, allow for more intelligent rewriting. r224742, r224798.

  • The masked load and store intrinsics have been documented. r224832.

  • CodeGenPrepare learned to speculate calls to llvm.cttz/ctlz (count trailing/leading zeroes) if isCheapToSpeculateCtlz/isCheapToSpeculatCttz in TargetLowering return true. r224899.

Clang commits

  • The Clang internals manual has been extended with stub sections on Parse, Sema, and CodeGen. r224894.

Other project commits

  • The libcxx LIT test-suite has seen a number of new configuration options. Even better, these are now documented. r224728.

by Alex Bradbury (noreply@blogger.com) at December 29, 2014 10:20 AM

LLVM Weekly - #50, Dec 15th 2014

Welcome to the fiftieth 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

I'll be at MICRO-47 this week. If you're there do say hi, especially if you want to chat about LLVM or lowRISC/RISC-V.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

The videos and slides from the 2014 LLVM dev meeting went online last week. I already linked to them then, but there's enough interesting stuff there I think I can justify linking again.

LLVM/Clang 3.5.1-rc1 has been tagged. Volunteer testers are very welcome.

Clang UPC 3.4.1 has been released. This is a Unified Parallel C compiler that can target SMP systems or Portals4.

On the mailing lists

LLVM commits

  • The LLVM Kaleidoscope tutorial has been extended with an 8th chapter, describing how to add debug information using DWARF And DIBuilder. r223671. A rendered version can be found here.

  • Extensive documentation has been added for the MergeFunctions pass. r223931.

  • A monster commit to split Metadata from the Value class hierarchy has landed. r223802.

  • InstrProf has been born. This involves the llvm.instrprof_increment instrinsic and the -instrprof pass. This moves logic from Clang's CodeGenPGO into LLVM. r223672.

  • With the addition of support for SELECT nodes, the MIPS backend now supports codegen of MIPS-II targets on the LLVM test-suite. Code generation has also been enabled for MIPS-III. r224124, r224128.

  • Work has started on an LLVM-based dsymutil tool, with the aim to replace Darwin's dsymutil (a DWARF linker). r223793.

  • LiveInterval has gained support to track the liveness of subregisters. r223877.

  • Work has started on converting moves to pushes on X86 when appropriate. r223757.

  • Print and verify passes are now added after each MachineFunctionPass by default, rather than on some arbitrarily chosen subset. r224042.

  • LLVM now requires Python 2.7. Previously 2.5 was required. r224129.

Clang commits

  • The __builtin_call_with_static_chain GNU extension has been implemented. r224167.

  • Clang's CodeGenPGO has moved to using the new LLVM -instrprof pass. r223683.

  • Clang now accepts Intel microarchitecture names as the -march argument. r223776.

Other project commits

  • libcxx gained relational operators in std::experimental::optional. r223775.

  • libcxx can now be built as a 32-bit library. r224096.

  • The lldb unwinder has learned to use unwind information from the compact-unwind section for x86-64 and i386 on Darwin. r223625.

by Alex Bradbury (noreply@blogger.com) at December 29, 2014 10:19 AM

LLVM Weekly - #51, Dec 22nd 2014

Welcome to the fifty-first 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

Last week as part of the lowRISC project I was involved in sharing our plans for tagged memory and 'minion' cores in the initial version. We've almost made it a full year of LLVM Weekly with no interruption of service!

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

3.5.1-rc2 has been tagged, time to get testing again.

Version 0.15.1 of LDC, the LLVM D Compiler has been released. The most prominent feature is probably the addition of preliminary support for MSVC on Win64.

SN Systems (part of Sony) have written a blog post describing their recently contributed ABI test suite.

Peter Wilmott has benchmarked Ruby across various GCC and Clang releases. The discussion at HN may be of interest.

On the mailing lists

LLVM commits

  • Metadata is now typeless in assembly. r224257.

  • PowerPC instruction selection for bit-permuting operations has been improved. r224318.

  • An optimisation has been added to move sign/zero extends close to loads which causes performance improvements of 2-3% on a few benchmarks on x86. r224351.

  • More overflow arithmetic intrinsics are strength reduced into regular arithmetic operations if possible. r224417.

Clang commits

  • Codegen for 'omp for' has started to be committed. r224233.

  • -save-temps will now emit unoptimized bitcode files. r224688.

Other project commits

  • The libcxx test suite can be run with ccache now. r224603.

  • Breakpoints can now be tagged with a name in lldb. r224392.

by Alex Bradbury (noreply@blogger.com) at December 29, 2014 10:19 AM

December 17, 2014

OpenMP Runtime Project

New code release

We are excited to announce the next release of the Intel® OpenMP* Runtime Library at openmprtl.org. This release aligns with Intel® Parallel Studio XE 2015 Composer Edition Update 2.

New Features

by mad\jlpeyton at December 17, 2014 07:47 PM

December 15, 2014

LLVM Blog

LLVM Weekly - #49, Dec 8th 2014

Welcome to the forty-ninth 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Most of the 2014 LLVM Developers' Meeting videos and slides are now online. Sadly, there are no videos from the talks by Apple employees yet. Hopefully they'll be appearing later.

QuarksLab has a rather nice write-up of deobfuscating an OLLVM-protected program.

The LLVM-based ELLCC has been making progress on ELK, a bare-metal POSIX-like environment.

Support for statepoints landed in LLVM this week, and Philip Reames has a blog post detailing some notes and caveats. See also the mailing list discussion linked to below about future plans for GC in LLVM.

On the mailing lists

LLVM commits

  • The statepoint infrastructure for garbage collection has landed. See the final patch in the series for documentation. r223078, r223085, r223137, r223143.

  • The LLVM assembler gained support for ARM's funky modified-immediate assembly syntax. r223113.

  • The OCaml bindings now has a CMake buildsystem. r223071.

  • The PowerPC backend gained support for readcyclecounter on PPC32. r223161.

  • Support for 'prologue' metadata on functions has been added. This can be used for inserting arbitrary code at a function entrypoint. This was previously known as prefix data, and that term has been recycled to be used for inserting data just before the function entrypoint. r223189.

  • PowerPC gained a Power8 instruction schedule definition r223257.

Clang commits

  • LLVM IR for vtable addresses now uses the type of the field being pointed to, to enable more optimisations. r223267.

  • New attributes have been added to specify AMDGPU register limits. This is a performance hint that can be used to attempt to limit the number of used registers. r223384.

  • Clang gained the __has_declspec_attribute preprocessor macro. r223467.

  • __has_attribute now only looks for GNU-style attributes. You should be able to use __has_cpp_atribute or __has_declspec_attribute instead. r223468.

Other project commits

  • DataFlowSanitizer is now supported for MIPS64. r223517.

  • libcxx now supported std::random_device on (P)NaCl. r223068.

  • An effort has started in lld to reduce abstraction around InputGraph, which has been found to get in the way of new features due to excessive information hiding. r223330. The commit has been temporarily reverted due to breakage on Darwin and ELF.

  • A large chunk of necessary code for Clang module support has been added to LLDB. r223433.

  • LLDB now has documented coding conventions. r223543.

by Alex Bradbury (noreply@blogger.com) at December 15, 2014 11:27 AM

December 01, 2014

LLVM Blog

LLVM Weekly - #48, Dec 1st 2014

Welcome to the forty-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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

John Regehr has posted an update on the Souper superoptimizer which he and his collaborators have been working on. They have implemented a reducer for Souper optimizations that tries to reduce the optimization to something more minimal. There current results given ~4000 distinct optimisations of which ~1500 LLVM doesn't know how to do. Of course many of these may in fact be covered by a single rule or pass. One of the next steps for Souper is to extend Souper to support the synthesis of instruction sequences. See also the discussion on the llvm mailing list.

The LLVM Blog features a summary of recent advances in loop vectorization for LLVM. This includes diagnostics remarks to get feedback on why loops which aren't vectorized are skipped, the loop pragma directive in Clang, and performance warnings when the directive can't be followed.

The LLVM Haskell Compiler (LHC) has been newly reborn along with its blog. The next steps in development are to provide better support for Haskell2010, give reusable libraries for name resolution and type checking, and to produce human-readable compiler output.

The next LLVM Social in Paris will take place on December 9th.

Intel have published a blog post detailing new X86-specific optimisations in GCC 5.0. You may also be interested in the discussion of this post on Hacker News.

On the mailing lists

LLVM commits

  • Support for -debug-ir (emitting the LLVM IR in debug data) was removed. There's no real justification or explanation in the commit message, but it's likely it was unfinished/unused/non-functional. r222945.

  • InstCombine will now canonicalize toward the value type being stored rather than the pointer type. The rationale (explained in more detail in the commit message) is that memory does not have a type, but operations and the values they produce do. r222748.

  • The documentation for !invariant.load metadata has been clarified. r222700.

  • In tablegen, neverHasSideEffects=1 is now hasSideEffects=0. r222801.

Clang commits

  • Four new ASTMatchers have been added: typedefDecl, isInMainFile, isInSystemFile, and isInFileMatchinName. r222646.

  • The documentation on MSVC compatibility has been updated to represent the current state of affairs. Clang has also gained support for rethrowing MS C++ exceptions. r222731, r222733.

Other project commits

  • Initial tests have been added for lldb-mi (the LLDB machine interface). r222750.

  • libcxxabi can now be built and tested without threads using CMake. r222702.

  • The compact-unwind-dumper tool now has complete support for x86-64 and i386 binaries. r222951.

by Alex Bradbury (noreply@blogger.com) at December 01, 2014 02:57 PM

November 25, 2014

LLVM Blog

Loop Vectorization: Diagnostics and Control

Loop vectorization was first introduced in LLVM 3.2 and turned on by default in LLVM 3.3. It has been discussed previously on this blog in 2012 and 2013, as well as at FOSDEM 2014, and at Apple's WWDC 2013. The LLVM loop vectorizer combines multiple iterations of a loop to improve performance. Modern processors can exploit the independence of the interleaved instructions using advanced hardware features, such as multiple execution units and out-of-order execution, to improve performance.

Unfortunately, when loop vectorization is not possible or profitable the loop is silently skipped. This is a problem for many applications that rely on the performance vectorization provides. Recent updates to LLVM provide command line arguments to help diagnose vectorization issues and new a pragma syntax for tuning loop vectorization, interleaving, and unrolling.

New Feature: Diagnostics Remarks

Diagnostic remarks provide the user with an insight into the behavior of the behavior of LLVM’s optimization passes including unrolling, interleaving, and vectorization. They are enabled using the Rpass command line arguments. Interleaving and vectorization diagnostic remarks are produced by specifying the ‘loop-vectorize’ pass. For example, specifying ‘-Rpass=loop-vectorize’ tells us the following loop was vectorized by 4 and interleaved by 2.

void test1(int *List, int Length) {
  int i = 0;
  while(i < Length) {
    List[i] = i*2;
    i++;
  }
}

clang -O3 -Rpass=loop-vectorize -S test1.c -o /dev/null

test1.c:4:5: remark: 
vectorized loop (vectorization factor: 4, unrolling interleave factor: 2)
    while(i < Length) {
    ^

Many loops cannot be vectorized including loops with complicated control flow, unvectorizable types, and unvectorizable calls. For example, to prove it is safe to vectorize the following loop we must prove that array ‘A’ is not an alias of array ‘B’. However, the bounds of array ‘A’ cannot be identified.

void test2(int *A, int *B, int Length) {
  for (int i = 0; i < Length; i++)
    A[B[i]]++;
}

clang -O3 -Rpass-analysis=loop-vectorize -S test2.c -o /dev/null

test2.c:3:5: remark:
loop not vectorized: cannot identify array bounds
    for (int i = 0; i < Length; i++)
    ^

Control flow and other unvectorizable statements are reported by the '-Rpass-analysis' command line argument. For example, many uses of ‘break’ and ‘switch’ are not vectorizable.

C/C++ Code-Rpass-analysis=loop-vectorize
for (int i = 0; i < Length; i++) {
  if (A[i] > 10.0)
    break;
  A[i] = 0;

}
control_flow.cpp:5:9: remark: loop not vectorized: loop control flow is not understood by vectorizer
    if (A[i] > 10.0)

        ^
for (int i = 0; i < Length; i++) {
  switch(A[i]) {
  case 0: B[i] = 1; break;
  case 1: B[i] = 2; break;
  default: B[i] = 3;
  }

}
no_switch.cpp:4:5: remark: loop not vectorized: loop contains a switch statement
    switch(A[i]) {

    ^

New Feature: Loop Pragma Directive

Explicitly control over the behavior of vectorization, interleaving and unrolling is necessary to fine tune the performance. For example, when compiling for size (-Os) it's a good idea to vectorize the hot loops of the application to improve performance. Vectorization, interleaving, and unrolling can be explicitly specified using the #pragma clang loop directive prior to any for, while, do-while, or c++11 range-based for loop. For example, the vectorization width and interleaving count is explicitly specified for the following loop using the loop pragma directive.

void test3(float *Vx, float *Vy, float *Ux, float *Uy, float *P, int Length) {
#pragma clang loop vectorize_width(4) interleave_count(4)
#pragma clang loop unroll(disable)
  for (int i = 0; i < Length; i++) {
    float A = Vx[i] * Ux[i];
    float B = A + Vy[i] * Uy[i];
    P[i] = B;
   }
}

clang -O3 -Rpass=loop-vectorize -S test3.c -o /dev/null

test3.c:5:5: remark:
vectorized loop (vectorization factor: 4, unrolling interleave factor: 4)
    for (int i = 0; i < Length; i++) {
    ^

Integer Constant Expressions

The options vectorize_width, interleave_count, and unroll_count take an integer constant expression. So it can be computed as in the example below.

template <int ArchWidth, int ExecutionUnits>
void test4(float *Vx, float *Vy, float *Ux, float *Uy, float *P, int Length) {
#pragma clang loop vectorize_width(ArchWidth)
#pragma clang loop interleave_count(ExecutionUnits * 4)
  for (int i = 0; i < Length; i++) {
    float A = Vx[i] * Ux[i];
    float B = A + Vy[i] * Uy[i];
    P[i] = B;
   }
}

void compute_test4(float *Vx, float *Vy, float *Ux, float *Uy, float *P, int Length) {
  const int arch_width = 4;
  const int exec_units = 2;
  test4<arch_width, exec_units>(Vx, Vy, Ux, Uy, P, Length);
}

clang -O3 -Rpass=loop-vectorize -S test4.cpp -o /dev/null

test4.cpp:6:5: remark:
vectorized loop (vectorization factor: 4, unrolling interleave factor: 8)
    for (int i = 0; i < Length; i++) {
    ^

Performance Warnings

Sometimes the loop transformation is not safe to perform. For example, vectorization fails due to the use of complex control flow. If vectorization is explicitly specified a warning message is produced to alert the programmer that the directive cannot be followed. For example, the following function which returns the last positive value in the loop, cannot be vectorized because the ‘last_positive_value’ variable is used outside the loop.

int test5(int *List, int Length) {
  int last_positive_index = 0;
  #pragma clang loop vectorize(enable)
  for (int i = 1; i < Length; i++) {
    if (List[i] > 0) {
      last_positive_index = i;
      continue;
    }
    List[i] = 0;
  }
  return last_positive_index;
}

clang -O3 -g -S test5.c -o /dev/null

test5.c:5:9: warning:
loop not vectorized: failed explicitly specified loop vectorization
    for (int i = 1; i < Length; i++) {
        ^

The debug option ‘-g’ allows the source line to be provided with the warning.

Conclusion

Diagnostic remarks and the loop pragma directive are two new features that are useful for feedback-directed-performance tuning. Special thanks to all of the people who contributed to the development of these features. Future work includes adding diagnostic remarks to the SLP vectorizer and an additional option for the loop pragma directive to declare the memory operations as safe to vectorize. Additional ideas for improvements are welcome.

by Tyler Nowicki (noreply@blogger.com) at November 25, 2014 01:34 AM

November 24, 2014

LLVM Blog

LLVM Weekly - #47, Nov 24th 2014

Welcome to the forty-seventh 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Version 3.0 of the Capstone disassembly framework has been released. Python bindings have been updated to support Python 3, and this release also adds support for Sparc, SystemZ and XCore. It also has performance improvements.

Herb Sutter has penned a trip report of the recent ISO C++ meeting.

Emscripten has updated to use LLVM 3.4 from the PNaCl team. There's more work to be done to rebase on top of 3.5.

Woboq has written a blog post detailing C++14 features of interest to Qt programmers, though I suspect the article has a wider potential audience than that. Recent Clang of course has good support for the new C++14 features.

There is going to be an LLVM Devroom at FOSDEM 2015, and the submission deadline for presentations/talks/tutorials is on Dec 1st.

Apple's LLVM Source Tools and Program Analysis teams are looking for interns for Summer 2015.

On the mailing lists

  • If you're wondering how the process of adding OpenMP support to Clang is going, the answer is that it's still ongoing and there's hope it will be done by the 3.6 release, depending on the speed of code reviews.

  • Siva Chandra kicked off a discussion on the mailing list about how to better manage breakages caused by LLVM or Clang API changes. Siva suggests LLDB should be developed against a known-good version of LLVM/Clang that gets periodically bumped. Vince Harron says that he is looking to add a continuous build on curated versions of Clang/LLVM in addition to a continuous build on top of tree for everything. This should help improve the signal to noise ratio and make it easier for LLDB developers to tell when a breaking change is due to their addition or a change elsewhere. Reid Kleckner suggests lldb should be treated part of the same project as Clang/LLDB and more pressure should be put on developers to fix breakages, presumably in the same way that API changes in LLVM almost always come with an associated patch to fix Clang.

  • Peter Collingbourne has proposed adding the llgo frontend to the LLVM project. Chris Lattner is in favour of this, but would like to see the GPLv3+runtime exception dependencies rewritten before being checked in. Some people in the thread expressed concern that the existing base of LLVM/Clang reviewers know C++ and may not be able to review patches in Go, though it looks like a non-zero of existing LLVM reviewers are appropriately multilingual.

  • Brett Simmers is working on HHVM and is interested if there are ways to control where a BasicBlock ends up in memory, with the motivation to make best of the instruction cache by keeping frequently executed pieces of code closer together. There's general agreement this would be a great feature to have, but it doesn't sound like this is easily supported in LLVM right now.

LLVM commits

  • A small doc fix has the honour of being commit 222222.

  • A nice little optimisation has been committed which replaces a switch table with a mul and add if there is a linear mapping between index and output. r222121.

  • The SeparateConstOffsetFromGEP, EarlyCSE, and LICM passes have been enabled on AArch64. This has measurable gains for some SPEC benchmarks. r222331.

  • The description of the noalias attribute has been clarified. r222497.

  • MDNode is being split into two classes, GenericMDNode and MDNodeFwdDecl. r222205.

  • The LLVM CMake-based build system learned to support LLVM_USE_SANITIZER=Thread. r222258.

  • The R600 backend gained the SIFoldOperands pass which attempts to fold source operands of mov and copy instructions into their uses. r222581.

Clang commits

  • Clang now distinguishes between -fpic and -fPIC. r222227.

  • The -Wuninitialized warning will now trigger when accessing an uninitialized base class in a constructor. r222503.

Other project commits

  • LLDB can now perform basic debugging operations on Windows. r222474.

  • LLDB's line editing support was been completely rewritten. r222163.

  • MemorySanitizer gained support for MIPS64. r222388.

  • A sample tool was added to lldb to extract and dump unwind information from Darwin's compact unwind section. r222127.

by Alex Bradbury (noreply@blogger.com) at November 24, 2014 02:00 PM

November 18, 2014

LLVM Blog

LLVM Weekly - #46, Nov 17th 2014

Welcome to the forty-sixth 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Chrome on Linux now uses Clang for production builds. Clang has of course been used on OS X Chrome for quite some time. The switch saw reduction in binary size of ~8%, but this was vs GCC 4.6 rather than something more up-to-date.

The LLVM in HPC workshop at SC14 is taking place on Monday and the full agenda with abstracts is available online

On the mailing lists

LLVM commits

  • Work on call lowering for MIPS FastISel has started. r221948.

  • Work has started on an assembler for the R600 backend. r221994.

  • A pass implementing forward control-flow integrity as been added. r221708.

  • A whole slew of patches that made MDNode a Value have been reverted due to a change in plan. The aim is now to separate metadata from the Value hierarchy. r221711.

  • There are two ways to inform the optimizer the result of a load is never null. Either with metadata or via assume. The latter is now canonicalized into the former. r221737.

  • vec_vsx_ld and vec_vsx_st intrinsics have been added for PowerPC. r221767.

  • PowerPC gained support for small-model PIC. r221791.

  • The llvm.arm.space intrinsic was added to make it easier to write tests for ARM ConstantIslands. r221903.

Clang commits

  • The constant trickle of OpenMP patches continues. Codegen for threadprivate variables has been added. r221663.

  • Support for __has_cpp_attribute is now present. r221991.

Other project commits

  • Breakpoint stop/resume has been implemented on Windows for LLDB. r221642.

  • The libcxx status page has been updated with the current state of C++1z support. r221601).

by Alex Bradbury (noreply@blogger.com) at November 18, 2014 01:43 PM

November 10, 2014

LLVM Blog

LLVM Weekly - #45, Nov 10th 2014

Welcome to the forty-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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Adrian Sampson has posted a status update on his Quala project to add custom type annotations to C and C++ in Clang/LLVM.

Bruce Mitchener has posted to the Dylan blog describing how Dylan integrates with LLVM. Interestingly, Dylan doesn't link with the LLVM libraries and instead generates bitcode files directly.

The Numba project has released llvmlite, lightweight python bindings to LLVM for writing JIT compilers. This was developed based on experience using the old llvmpy bindings.

Obfuscator-LLVM has been updated to work with LLVM 3.5.

On the mailing lists

LLVM commits

  • The PBQP register allocator has had its spill costs and coalescing benefits tweaked. This apparently results in a few percent improvement on benchmarks such as EEMBC and SPEC. r221292, r221293.

  • The new SymbolRewriter pass is an IR to IR transformation allowing adjustment of symbols during compilation. It is intended to be used for symbol interpositioning in sanitizers and performance analysis tools. r221548.

  • Hexagon gained a basic ELF object emitter. r221465.

  • llvm-vtabledump gained support for the Itanium ABI. r221133.

  • LLVM's CMake build system gained the LLVM_BUILD_STATIC option. r221345.

  • The usage of Inputs/ for extra test files has been documented. r221406.

  • The MIPS backend has reached a milestone in support for the N32/N64 ABI. This commit fixes all known bugs for this ABI and the first 10000 tests generated by ABITest.py pass. r221534.

Clang commits

  • clang-format gained various improvements for formatting Java code. r221104, r221109, and others.

  • Support was added for C++1z nested namespace definitions, u8 character literals, and attributes on namespaces or enumerators. r221574, r221576, r221580.

Other project commits

  • LLD learned how to parse most linker scripts. Before getting too excited, do note this is parsing only, semantic actions will come in the future. r221126.

  • The common Sanitizer code gained a generic stack frame renderer. This allows the user to control the format of stack frame output. r221409, r221469.

  • The basic framework for live debugging on Windows was added to LLDB. It will detect changes such as DLL loads and unloads etc, but these need to be propagated through LLDB properly. r221207.

  • lldb-gdbserver now supports the Android target. r221570.

by Alex Bradbury (noreply@blogger.com) at November 10, 2014 01:11 PM

November 03, 2014

LLVM Blog

LLVM Weekly - #44, Nov 3rd 2014

Welcome to the forty-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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

The 2014 LLVM Dev meeting was held last week. I couldn't make it, but it seems like there was a great selection of talks. Sadly the keynote about Swift's high-level IR was cancelled. No word yet on when we can expect slides and videos online. However, slides by Philip Reames and Sanjoy Das from their talk on on implementing fully relocating garbage collection in LLVM are online.

Peter Zotov has been doing lots of work on the LLVM OCaml bindings recently, and is looking for additional help. Recently, he's closed almost all open bugs for the bindings, migrated them to ocamlfind, fixed Lllvm_executionengine, and ensured pretty much the whole LLM-C API is exposed. Tasks on the todo list include writing tests in OUnit2 format, migrating the Kaleidoscope tutorial off camlp4, and splitting up and adding OCaml bindings to this patch. More ambitiously, it would be interesting to writing LLVM passes in OCaml and to represent LLVM IR as pure AST. If any of this interests you, do get in touch with Peter. He's able to review any patches, but could do with help on working through this list of new features.

The LLVM Bay Area monthly social is going to be held on 6th November.

On the mailing lists

  • Reid Kleckner has proposed dropping support for running LLVM on Windows XP. This would allow the use of system APIs only available in Vista and above. Thus far all responses have been positive, with one even suggesting raising the minimum to Windows 7.

  • Tom Stellard suggests deprecating the autoconf build system. Right now there is both an autotools based system and a CMake system, though CMake seems most used by developers for LLVM at least. Bob Wilson points out that the effort required to keep the existing makefiles working is much less than what might be needed to update the CMake build to support all uses cases. Though other replies make it seems that the CMake build supports pretty much all configurations people use now. If there are people who actually enjoy fiddling with build systems (far-fetched, I know), it seems like a little effort could go a long way and allow the makefile system to be jettisoned.

  • Betul Buyukkurt has posted an RFC on indirect call target profiling. The goal is to use the collected data for optimisation. Kostya Serebryany described how it can be used to provide feedback to fuzzers and detailed properties that would be useful for this usecase.

  • Chris Matthews announces that a new Jenkins-based OSX build cluster is up and running. This includes multiple build profiles and an O3 LTO performance tracker. The Jenkins config should be committed to zorg soon.

LLVM commits

  • Support for writing sampling profiles has been committed. In the future, support to read (and maybe write) profiles in GCC's gcov format will be added, and llvm-profdata will get support to manipulate sampling profiles. r220915.

  • A comment has been added to X86AsmInstrumentation to describe how asm instrumentation works. r220670.

  • The Microsoft vectorcall calling convention has been implemented for x86 and x86-64. r220745.

  • The C (and OCaml) APIs gained functions to query and modify branches, and to obtain the values for floating point constants. There have been a whole bunch of additional commits related to the OCaml bindings, too many to pick out anything representative. r220814, r220815, r220817, r220818.

  • The loop and SLP (superword level parallelism) vectorizers are now enabled in the Gold plugin. r220886, r220887.

Clang commits

  • A refactoring of libTooling to reduce required dependencies means that clang-format's binary is now roughly half the size. r220867.

Other project commits

  • lldb has started to adopt the StringPrinter API. r220894.

  • Initial support for PowerPC/PowerPC64 on FreeBSD has been added to LLDB. r220944.

by Alex Bradbury (noreply@blogger.com) at November 03, 2014 11:29 AM

October 27, 2014

LLVM Blog

LLVM Weekly - #43, Oct 27th 2014

Welcome to the forty-third 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

This week it's the LLVM Developers' Meeting in San Jose. Check out the schedule. Unfortunately I won't be there, so I'm looking forward to the slides and videos going online.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Philip Reames has written up a detailed discussion of statepoints vs gcroot for representing call safepoints. The aim is to clearly explain how the safepoint functionality provided by the patches currently up for review differ to the current gc.root support.

The Haskell community have put together a proposal for an improved LLVM backend to GHC. They intend to ship GHC with its own local LLVM build.

CoderGears have published a blog post about using Clang to get better warnings in Visual C++ projects.

There is going to be a dedicated LLVM devroom at FOSDEM 2015. Here is the call for speakers and participation.

On the mailing lists

LLVM commits

  • The nonnull metadata has been introduced for Load instructions. r220240.

  • minnum and maxnum intrinsics have been added. r220341, r220342.

  • The Hexagon backend gained a basic disassembler. r220393.

  • PassConfig gained usingDefaultRegAlloc to tell if the default register allocator is being used. r220321.

  • An llvm-go tool has been added. It is intended to be used to build components such as the Go frontend in-tree. r220462.

Clang commits

  • C compilation defaults to C11 by default, matching the behaviour of GCC 5.0. r220244.

  • Clang should now be better at finding Visual Studio in non-standard setups. r220226.

  • The Windows toolchain is now known as MSVCToolChain, to allow the addition a CrossWindowsToolChain which will use clang/libc++/lld. r220362, r220546.

Other project commits

  • The libcxxabi gained support for running libc++abi tests with sanitizers. r220464.

by Alex Bradbury (noreply@blogger.com) at October 27, 2014 11:02 AM

October 21, 2014

Philip Reames

Statepoints vs gcroot for representing call safepoints

I recent discussion on LLVM commits w.r.t. the statepoint changes which are up for review, I managed to get myself confused and made a couple of inaccurate statements regarding the existing capabilities of gcroots vs the newly proposed statepoints.  This post is a (hopefully correct) summary of the similarities and differences.

For the purposes of this post, I am only talking about the semantics of the collector at a source language level call site.  The issues highlighted with gc root and safepoint poll sites in my previous post still stand, but I didn’t do a very good job (in retrospect) of distinguishing between safepoints at call sites, and additional checks + runtime calls inserted to ensure that running code checks for a safepoint request at some interval.  The points in that post apply to the later; this one talks about the former.

From a functional correctness standpoint, gc.root and statepoint are equivalent.  They can both support relocating collectors, including those which relocate roots.  To prevent future confusion, let me review how each works.

gc.root uses explicit spill slots in the IR in the form of allocas.  Each alloca escapes (through the gcroot call itself); as a result, the compiler must assume that any readwrite call can both consume and update the values in question.  Additionally, the fact that all calls are readwrite prevents reordering of unrelated loads past the call.  gcroot relies on the fact that no SSA value relocated at a call site is used at a site reachable from the call.  Instead, a new SSA value (whose relation to the original is unknown by the compiler) is introduced by loading from the (potentially clobbered) alloca.  gcroot creates a single stack map table for the entire function.  It is the compiled code’s responsibility to ensure that all values in the allocas are either valid live pointers or null.

Statepoints use most of the same techniques.  We rely on not having an SSA value used on both sides of a call, but we manage the relocation via explicit IR relocation operations, not loads and stores.  We require the call to be read/write to prevent reordering of unrelated loads.  Since the spill slots are not visible in the IR, we do not need the reasoning about escapes that gc.root does.

To explicitly state this again since I screwed this up once before, both statepoints and gc.roots can correctly represent relocation semantics in the IR.  In fact, the underlying reasoning about their correctness are rather similar.

They do differ fairly substantially in the details though.  Let’s consider a few examples.

SSA vs Memory – gcroot encodes relocations as memory operations (stores, clobbering calls, loads) where statepoint uses first class SSA values.  We believe this makes optimizations more straightforward.

Consider a simple optimization for null pointer relocation.  If the optimizer manages to establish that one of the value being relocated is null, propagating this across a statepoint is straightforward.  (For each gc.relocate, if source is null, replaceAllUsesWith null.)  Implementing this same optimization for gc.root is harder since the store and load may have been reordered from immediately around the call.  This isn’t an unsolvable problem by any means, but it would be a GVN change, not an InstCombine one.  In practice, we believe InstCombine style optimizations to be advantageous since they’re simpler to write and debug.  Arguably, they’re also more powerful given the current pipeline since they have multiple opportunities to trigger.

Derived Pointers – gcroot can represent derived pointers, but only via convention.  There is no convention specified, so it’s up to the frontend to create it’s own.  Statepoints define a convention (explicitly in the relocation operation) which makes describing optimizations straight forward.

One thing we plan to do with the statepoint representation is to implement an “easily derived pointer” optimization (to run near CodeGenPrep).  On X86, it’s far cheaper to recreate a GEP base + 5 derived pointer than relocate it.  Recognizing this case is quite straight forward given the statepoint representation.

A frontend could implement a similar optimization for gcroot at IR generation time.  You could also implement such an optimization over the load/call/store representation, but the implementation would be much more complex (analogous to the null optimization above).

To be fair, gc.root may need such an optimization less.  Since call-safepoints are inserted early, CSE has not yet run.  As a result, there may be fewer “easily derived pointers” live across a call.

Format – Statepoints use a standard format.  gc.root supports custom formats.  Either could be extended to support the other without much difficulty.

The more material difference between the two is that gc.root generates a single stack map for the entire function while statepoints generate a unique stack map per call site.  Having a single stack map imposes a slight penalty on code compiled with gc.root since dead values must explicitly be removed from the alloca (by a write of null).  In the wrong situation (say a tight loop with two calls), this could be material.

Lowering – Currently, both gc.root and statepoint lower to stack slots.  gc.root does this at the IR level, statepoints does so in SelectionDAG.

The design of statepoints is intended to allow pushing the explicit relocations back through the backend.  The reason this is desirable is that pointers can be left in callee saved registers over call sites.  Without substantial re-engineering, such a thing is not possible for gc.root.  The importance of this from a performance perspective is debatable.  It is my belief that the key benefit would be in a) reducing frame sizes (by not requiring spill slots), and b) avoiding spills around calls.

An advantage of gc.root is that the backend can remain largely ignorant of the gc.root mechanism.  By the point the backend encounters them, a gc.root is just another alloca.  One potential problem with the current implementation is that the escape is lost when lowering; the gcroot call is lowered to an entry into a side table and the alloca no longer escapes.  This is a source of possible bugs, but is also a straightforward fix.

As to the lowering currently implemented, it’s debatable which is better.  Statepoints optimize constants, and unifies based on SDValue.  As a result, two IR level values of different types (with the same bit pattern) can end up sharing the same stackslot.  However, it suffers when trying to assign stack slots.  We currently use heuristics, but you can end up with ugly shuffling of values around on the stack across basic blocks.  (There’s a number of ways to improve that, but it’s not yet implemented.)  gc.root doesn’t suffer from this problem since stack slots are assigned by the frontend.

Since the stack spills and reloads are visible at the IR layer, gcroot gets the full ability of the optimizer to remove redundant reloads.  Statepoints only get to leverage the pieces in the backend.  In theory, this could result in materially worse spill/reload code for statepoints.  In practice, this appears not to matter much provided the same value is assigned to the same slot across both calls, but I don’t actually have much data here to say anything conclusively yet.

I haven’t tried to measure frame size for gc.root vs statepoints.  I suspect that statepoints may come out slightly ahead, but I doubt this is material.  There are also cases (see “easily derived pointers” above), where gc.root may come out ahead.

IR Level Optimization – Both gc.root and statepoints cripple optimization (by design!).  gcroot works better with inlining today, but statepoints could be easily enhanced to handle this case.  (The same work would benefit symbolic patchpoints.)

It is my belief that statepoints are easier to optimize (i.e. teach to LICM), but this is purely my guess with no real evidence.  Both suffer from the fact that calls must be marked readwrite.  Not having to reason about memory seems easier, but I’m open to other arguments here.

Community Support & Compatibility
From a practical perspective, statepoints have active users behind them.  We are interested in continuing to enhance and optimize them in the public tree.  The same support does not seem to exist for gcroot.

The implementation of statepoints is largely aligned with that of patchpoints.  The implementation of gcroot is completely separate and poorly understood by the majority of the community.

It wouldn’t be hard to write a translation pass from gcroot to statepoints or from statepoints to gcroot.  If folks are concerned about compatibility, this would be a reasonable option.  The largest challenge to transparently replacing one with the other is in generating the right output format.

Summary
To summarize, gcroot and statepoints are functionally equivalent (modulo possible bugs.)  In their current form, the two are largely comparable with each having some benefits.  Long term, we believe a statepoint representation will allow better code generation and IR level optimization of code with safepoints inserted.  We believe statepoints to be easier to optimize both at the IR level and backend.

Again, the late safepoint proposal is independent and could be done with either representation.  It’s currently implemented on statepoints, but it could be extended to gcroot without too much work.

by reames at October 21, 2014 09:42 PM

October 20, 2014

OpenMP Runtime Project

LLVM in Clang Developers Meeting

In case you missed it, you may like to know that there will be a talk on "OpenMP* Support in Clang/LLVM: Status Update and Future Directions" at the LLVM developers' meeting http://www.llvm.org/devmtg/2014-10/ in a couple of weeks' time.

by mad\efroeder at October 20, 2014 01:13 PM

LLVM Blog

LLVM Weekly - #42, Oct 20th 2014

Welcome to the forty-second 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

If you're local to London, you may be interested to know that I'll be talking about lowRISC at the Open Source Hardware User Group on Thursday.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

ELLCC, the LLVM-based cross-compilation toolchain now has pre-built binaries for all LLVM tools.

Eli Bendersky's repository of examples for using LLVM and Clang as libraries and for building new passes aren't new, but they are incredibly useful for newcomers to LLVM/Clang and I haven't featured them before. If you want to build something using LLVM or Clang, the llvm-clang-samples repos is one of the best places to start.

On the mailing lists

LLVM commits

  • Go LLVM bindings have been committed. r219976.

  • Invoking patchpoint intrinsics is now supported. r220055.

  • LLVM gained a workaround for a Cortex-A53 erratum. r219603.

  • Basic support for ARM Cortex-A17 was added. r219606.

  • The C API has been extended with the LLVMWriteBitcodeToMemoryBuffer function. r219643.

  • NumOperands has been moved from User to Value. On 64-bit host architectures this reduces sizeof(User) and subclasses by 8. r219845.

  • The LLVMParseCommandLineOptions was added to the C API. r219975.

Clang commits

  • Constant expressions can now be used in pragma loop hints. r219589.

  • The libclang API gained a function to retrieve the storage class of a declaration. r219809.

  • With the -fsanitize-address-field-padding flag, Clang can insert poisoned paddings between fields in C++ classes to allow AddressSanitizer to find intra-object overflow bugs. r219961.

Other project commits

  • lldb now supports a gdb-style batch mode. r219654.

by Alex Bradbury (noreply@blogger.com) at October 20, 2014 11:31 AM

LLVM Weekly - #41, Oct 13th 2014

Welcome to the forty-first 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

I've been in Munich for ORCONF this weekend. Slides from my talk about lowRISC are available here.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

ELLCC, the LLVM/Clang-based cross development toolkit now has Windows binaries available.

IBM have posted a bounty on fixing the AddressSanitizer tests that fail on PowerPC.

GCC needs you! A large number of potential starting points for new contributors has been posted to the GCC mailing list.

On the mailing lists

LLVM commits

  • Switches with only two cases and a default are now optimised to a couple of selects. r219223.

  • llvm-symbolizer will now be used to symbolize LLVM/Clang crash dumps. r219534.

  • The calculation of loop trip counts for loops with multiple exits has been de-pessimized. r219517.

  • MIPS fast-isel learnt integer and floating point compare and conditional branches. r219518, r219530, r219556.

  • R600 gained a load/store machine optimizer pass. r219533.

Clang commits

  • The integrated assembler has been turned on by default for ppc64 and ppc64le. r219129.

  • clang-format's interpretation of special comments to disable formatting within a delimited range has been documented. r219204.

  • The integrated assembler has been turned on by default for SystemZ. r219426.

Other project commits

  • lld gained support for 'fat' mach-o archives. r219268.

  • The lldbtk example has seen some further development. r219219.

  • lldb-gdbserver can now be used for local-process Linux debugging. r219457.

  • The disassembly format for lldb can now be customized. r219544.

by Alex Bradbury (noreply@blogger.com) at October 20, 2014 11:31 AM

October 14, 2014

Philip Reames

Statepoint changes up for review

Last week, the first set of patches for our work on garbage collection support in LLVM hit the mailing list.  The review process will probably take a few weeks, but hopefully these should have landed by the 2014 LLVM Developers Meeting at the end of this month.  At that conference, my co-worker Sanjoy and I are going to be giving a talk about our progress on statepoints, and late safepoint placement.

Here’s the full text of the review request, along with a couple of updates:

Title: [Patch] Statepoint infrastructure for garbage collection

The attached patch implements an approach to supporting garbage collection in LLVM that has been mentioned on the mailing list a number of times by now.  There’s a couple of issues that need to be addressed before submission, but I wanted to get this up to give maximal time for review.

The statepoint intrinsics are intended to enable precise root tracking through the compiler as to support garbage collectors of all types.  Our testing to date has focused on fully relocating collectors (where pointers can change at any safepoint poll, or call site), but the infrastructure should support collectors of other styles.  The addition of the statepoint intrinsics to LLVM should have no impact on the compilation of any program which does not contain them.  There are no side tables created, no extra metadata, and no inhibited optimizations.

A statepoint works by transforming a call site (or safepoint poll site) into an explicit relocation operation.  It is the frontend’s responsibility (or eventually the safepoint insertion pass we’ve developed, but that’s not part of this patch) to ensure that any live pointer to a GC object is correctly added to the statepoint and explicitly relocated.  The relocated value is just a normal SSA value (as seen by the optimizer), so merges of relocated and unrelocated values are just normal phis.  The explicit relocation operation, the fact the statepoint is assumed to clobber all memory, and the optimizers standard semantics ensure that the relocations flow through IR optimizations correctly.

During the lowering process, we currently spill aggressively to stack.  This is not entirely ideal (and we have plans to do better), but it’s functional, relatively straight forward, and matches closely the implementations of the patchpoint intrinsics.  We leverage the existing StackMap section format, which is already used by the patchpoint intrinsics, to report where pointer values live.  Unlike a patchpoint, these locations are known (by the backend) to be writeable during the call.  This enables the garbage collector to transparently read and update pointer values if required.  We do optimize lowering in certain well known cases (constant pointers, a.k.a. null, being the key one.)

There are a few areas of this patch which could use improvement:

  • The patch needs rebased against TOT.  It’s currently based against a roughly 3 week old snapshot. (FIXED)
  • The intrinsics should probably be renamed to include an “experimental” prefix.
  • The usage of Direct and Indirect location types are currently inverted as compared to the definition used by patchpoint.  This is a simple fix. (FIXED)
  • The test coverage could be improved.  Most of the tests we’ve actually been using are built on top of the safepoint insertion mechanism (not included here) and our runtime.  We need to improve the IR level tests for optimizer semantics (i.e. not doing illegal transforms), and lowering.  There are some minimal tests in place for the lowering of simple statepoints.
  • The documentation is “in progress” (to put it kindly.)  (MUCH IMPROVED, MORE TODO)
  • Many functions are missing doxygen comments
  • There’s a hack in to force the use of RSP+Offset addressing vs RBP-Offset addressing for references in the StackMap section.  This works, shouldn’t break anyone else, but should definitely be cleaned up.  The choice of addressing preference should be up to the runtime.

When reviewing, I would greatly appreciate feedback on which issues need to be fixed before submission and those which can be addressed afterwards.  It is my plan to actively maintain and enhance this infrastructure over next few months (and years).  It’s already been developed out of tree entirely too long (our fault!), and I’d like to move to incremental work in tree as quickly as feasible.

Planned enhancements after submission:

  • The ordering of arguments in statepoints is essentially historical cruft at this point.  I’m open to suggestions on how to make this more approachable.  Reordering arguments would (preferably) be a post commit action.
  • Support for relocatable pointers in callee saved registers over call sites.  This will require the notation of an explicit relocation psuedo op and support for it throughout the backend (particularly the register allocator.)
  • Optimizations for non-relocating collectors.  For example, the clobber semantics of the spill slots aren’t needed if the collector isn’t relocating roots.
  • Further optimizations to reduce the cost of spilling around each statepoint (when required at all).
  • Support for invokable statepoints.
  • Once this has baked in tree for a while, I plan to delete the existing gc_root code.  It is unsound, and essentially unused.

In addition to the enhancements to the infrastructure in the currently proposed patch, we’re also working on a number of follow up changes:

  • Verification passes to confirm that safepoints were inserted in a semantically valid way (i.e. no memory access of a value after it has been inserted)
  • A transformation pass to convert naive IR to include both safepoint polling sites, and statepoints on every non-leaf call.  This transformation pass can be used at initial IR creation time to simplify the frontend authors’ work, but is also designed to run on *fully optimized* IR, provided the initial IR meets certain (fairly loose) restrictions.
  • A transformation pass to convert normal loads and stores into user provided load and store barriers.
  • Further optimizations to reduce the number of safepoints required, and improve the infrastructure as a whole.

We’ve been working on these topics for a while, but the follow on patches aren’t quite as mature as what’s being proposed now.  Once these pieces stabilize a bit, we plan to upstream them as well.  For those who are curious, our work on those topics is available here: https://github.com/AzulSystems/llvm-late-safepoint-placement

http://reviews.llvm.org/D5683

by reames at October 14, 2014 12:10 AM

October 06, 2014

LLVM Blog

LLVM Weekly - #40, Oct 6th 2014

Welcome to the fortieth 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

I'll be in Munich next weekend for the OpenRISC conference where I'll be presenting on the lowRISC project to produce an open-source SoC. I'll be giving a similar talk in London at the Open Source Hardware User Group on 23rd October.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Capstone 3.0 RC1 has been released Capstone is an open source disassembly engine, based initially on code from LLVM. This release features support for Sparc, SystemZ and XCore as well as the previously supported architectures. Among other changes, the Python bindings are now compatible with Python 3.

An interesting paper from last year came up on the mailing list. From EPFL, it proposes adding -OVERIFY to optimise programs for fast verification. The performance of symbolic execution tools is improved by reducing the number of paths to explore and the complexity of branch conditions. They managed a maximum 95x reduction in total compilation and analysis time.

The next Cambridge (UK) social will take place on Wed 8th Oct at 7.30 pm.

On the mailing lists

LLVM commits

  • The expansion of atomic loads/stores for PowerPC has been improved. r218922. The documentation on atomics has also been updated. r218937.

  • For the past few weeks, Chandler Carruth has been working on a new vector shuffle lowering implementation. There have been too many commits to summarise, but the time has come and the new codepath is now enabled by default. It claims 5-40% improvements in the right conditions (when the loop vectorizer fires in the hot path for SSE2/SSE3). r219046.

  • The Cortex-A57 scheduling model has been refined. r218627.

  • SimplifyCFG now has a configurable threshold for folding branches with common destination. Changing this threshold can be worthwhile for GPU programs where branches are expensive. r218711.

  • Basic support for the newly-announced Cortex-M7 has been added. r218747.

  • As discussed on the mailing list last week, the sqrt intrinsic will now return undef when given a negative input. r218803.

  • llvm-readobj learnt -coff-imports which will print out the COFF import table. r218891, r218915.

Clang commits

  • Support for the align_value attribute has been added, matching the behaviour of the attribute in the Intel compiler. The commit message explains why this attribute is useful in addition to aligned. r218910.

  • A rather useful diagnostic has been added. -Winconsistent-missing-override will warn if override is missing on an overridden method if that class has at least one override specified on its methods. r218925.

  • Support for MS ABI continues. thread_local is now supported for global variables. r219074.

  • Matcher and DynTypedMatcher saw some nice performance tweaking, resulting in a 14% improvement on a clang-tidy benchmark and compilation of Dynamic/Registry.cpp sped up by 17%. r218616.

  • lifetime.start and lifetime.end markers are now emitted for unnamed temporary objects. r218865.

  • The __sync_fetch_and_nand intrinsic was re-added. See the commit message for a history of its removal. r218905.

  • Clang gained its own implementation of C11 stdatomic.h. The system header will be used in preference if present. r218957.

  • Clang now understands -mthread-model to specify the thread model to use, e.g. posix, single (for bare-metal and single-threaded targets). r219027.

Other project commits

  • libcxxabi should now work with the ARM Cortex-M0. r218869.

  • lldb gained initial support for scripting stepping. This is the ability to add new stepping modes implemented by python classes. The example in the follow-on commit has a large comment at the head of the file to explain its operation. r218642, r218650.

by Alex Bradbury (noreply@blogger.com) at October 06, 2014 12:49 PM

October 02, 2014

OpenMP Runtime Project

New code release

We are excited to announce the next release of the Intel® OpenMP* Runtime Library at openmprtl.org. This release aligns with Intel® Parallel Studio XE 2015.

New Features

  • Contribution from ScaleMP*: stack padding.
  • Redesign of wait and release code; performance improvements.

Bug Fixes

by mad\egfefey at October 02, 2014 09:15 PM

September 30, 2014

LLVM Blog

LLVM Weekly - #39, Sep 29th 2014

Welcome to the thirty-ninth 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

An implementation of Common Lisp with an LLVM backend, Clasp, has been announced. There's a lot of work to be done on performance, but development is very active on Github.

A backend for the educational 'y86' instruction set architecture has been started. The source is on Github.

A new binary snopshot of the ELLCC cross compilation toolchain is now available. Pre-compiled binaries are available for ARM, MIPS, PPC, and x86. All tarballs contain header files and runtime libraries for all targets to allow you to build for any supported target.

On the mailing lists

LLVM commits

  • Segmented stacks support for the x32 ABI has been fixed. r218247.

  • Robin Morisset's work on optimisation of atomics continues. AtomicExpandPass now inserts fences itself rather than SelectionDAGBuilder. r218329.

  • LLVM's libSupport gained a type-safe alternative to llvm::format(). r218463.

  • llvm-vtabledump learned how to dump RTTI structures for the MS ABI. r218498.

Clang commits

  • The assume_aligned function attribute is now supported. r218500.

  • The thread safety analysis documentation has seen a hefty update. r218420.

  • MS compatibility is further improved with support for the __super scope specifier. r218484.

Other project commits

  • ASan in compiler-rt gained the start of a debugging API. r218538.

  • LLDB gained the beginnings of an example Tk UI. r218279.

by Alex Bradbury (noreply@blogger.com) at September 30, 2014 08:53 AM

September 22, 2014

LLVM Blog

LLVM Weekly - #38, Sep 22nd 2014

Welcome to the 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

I've been at PyConUK this past weekend so I'm afraid it's another slightly shorter than normal issue. I've been talking about Pyland, a programming game that aims to teach children programming in Python (and of course, runs on Raspberry Pi).

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

A paper has recently been published about Harmony. In the words of the authors "Harmony is an open source tool (built as an LLVM pass) that creates a new kind of application profile called Parallel Block Vectors, or PBVs. PBVs track dynamic program parallelism at basic block granularity to expose opportunities for improving hardware design and software performance." Their most recent paper on ParaShares describes how they find the most 'important' basic blocks in multithreaded programs.

Richard Pennington has written up some more thoughts on cross compilation configuration for Clang.

Clike is a low-level programming language with an extensible syntax based on C. It of course targets LLVM.

If you want your Emacs editor to automatically disassemble LLVM bitcode inside Emacs buffers, then autodisass-llvm-bitcode is for you.

On the mailing lists

LLVM commits

  • The LLVM MC layer can now write BigObj-style COFF object files. r217812.

  • X86AtomicExpandPass has been removed in favour of using the generic AtomicExpandHooks (which now has the necessary hooks). r217928.

  • llvm-cov's internal API has been reworked. r217975.

Clang commits

  • Clang can now use 'response files' when calling other tools when the length of the command line exceeds system limits. r217792.

  • The -Wbind-to-temporary-copy warning is no longer on by default. r218008.

  • Clang's thread safety analysis gained -Wthread-safety-reference which warns when a guarded variable is passed by reference as a function argument. r218087.

Other project commits

  • libcxx gained some support for using newlib as its C library. r218144.

by Alex Bradbury (noreply@blogger.com) at September 22, 2014 03:57 PM

September 15, 2014

LLVM Blog

LLVM Weekly - #37, Sep 15th 2014

Welcome to the thirty-seventh 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

This week's issue comes to you from sunny Tenerife. Yes, my dedication to weekly LLVM updates is so great that I'm writing it on holiday. Enjoy! I'll also note that I'm at PyCon UK next week where I'll be presenting on the results of a project we had some interns working on over the summer creating a programming game for the Raspberry Pi.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Not only does Pyston have a shiny new blog, they've also released version 0.2. Pyston is an implementation of Python using LLVM, led by Dropbox. This release supports a range of language features that weren't supported in 0.1, including support for the native C API. The plan is to focus on performance during the development cycle for 0.3.

Sylvestre Ledru has posted a report of progress in building Debian with Clang following the completion of this year's Google Summer of Code projects. Now with Clang 3.5.0 1261 packages fail to build with Clang. Sylvestre describes how they're attacking the problem from both sides, by submitting patches to upstream projects as well as to Clang where appropriate (e.g. to ignore some unsupported optimisation flags rather than erroring out).

On the mailing lists

  • Philip Reames has started a discussion on adding optimisation hints for 'constant' loads. A common case is where a field is initialised exactly once and then is never modified. If this invariant could be expressed, it could improve alias analysis as the AA pass would never consider that field to MayAlias with something else (Philip reports that the obvious approach of using type-based alias analysis isn't quite enough).

  • Hal Finkel has posted an RFC on attaching attributes to values. Currently, attributes such as noalias and nonnull can be attached to function parameters, but in cases such as C++11 lambdas these can be packed up into a structure and the attributes are lost. Some followup discussion focused on whether these could be represented as metadata. The problem there of course is that metadata is intended to be droppable (i.e. is semantically unimportant). I very much like the suggestion from Philip Reames that the test suite should run with a pass that forcibly drops metadata to verify it truly is safe to drop.

  • Robin Morisset has posted a proposal on implementing a fence elimination algorithm. The proposed algorithm is based on partial redundancy elimination. He's looking for feedback on the suggested implementation approach.

  • There's been a little bit of discussion on the topic of rekindling work on VMKit.

LLVM commits

  • The start of the llvm.assume infrastructure has been committed, as well as an AlignmentFromAssumptions pass. See the original RFC for a refresher on the llvm.assume intrinsic. r217342, r217344.

  • LLVM's sample profile reader has been refactored into lib/ProfileData. r217437.

  • The AMD 16H Jaguar microarchitecture now has a scheduling model. r217457.

  • The 'bigobj' COFF variant can now be read. r217496.

Clang commits

  • The __builtin_assume and __builtin_assume_aligned intrinsics have been added. r217349.

  • The thread safety TIL (Typed Intermediate Language) has seen a major update. r217556.

Other project commits

  • LLD gained support for AArch64 Mach-O. r217469.

by Alex Bradbury (noreply@blogger.com) at September 15, 2014 02:01 PM

September 11, 2014

Sylvestre Ledru

Rebuild of Debian using Clang 3.5.0

Clang 3.5.0 has just been released. A new rebuild has been done highlight the progress to get Debian built with clang.

tl;dr: Great progress. We decreased from 9.5% to 5.7% of failures. Full results are available on http://clang.debian.net

At time of the rebuild with 3.4.2, we had 2040 packages failing to build with clang. With 3.5.0, this dropped to 1261 packages.

Fixes

With Arthur Marble and Alexander Ovchinnikov, both GSoC students, we worked on various ways to decrease the number of errors.

Upstream fixes

First, the most obvious way, we fixed programming bugs/mistakes in upstream sources. Basically, we took categories of failure and fixed issues one after the other. We started with simple bugs like 'Wrong main declaration', 'non-void function should return a value' or 'Void function should not return a value'.

They are trivial to fix. We continued with harder fixes like ' Undefined reference' or 'Variable length array for a non POD (plain old data) element'.

So, besides these one, we worked on:


In total, we reported 295 bugs with patches. 85 of them have been fixed (meaning that the Debian maintainer uploaded a new version with the fix).

In parallel, I think that the switch by FreeBSD and Mac OS X to Clang also helped to fix various issues by upstreams.

Hacking in clang

As a parallel approach, we started to implement a suggestion from Linus Torvalds and a few others. Instead of trying to fix all upstream, where we can, we tried to update clang to improve the gcc compatibility.

gcc has many flags to disable or enable optimizations. Some of them are legacy, others have no sense in clang, etc. Instead of failing in clang with an error, we create a new category of warnings (showing optimization flag '%0' is not supported) and moved all relevant flags into it. Some examples, r212805, r213365, r214906 or r214907

We also updated clang to silent some useless arguments like -finput-charset=UTF-8 (r212110), clang being UTF-8 compliant.

Finally, we worked on the forwarding of linker flags. Clang and gcc have a very different behavior: when gcc does not know an argument, it is going to forward the argument to the linker. Clang, in this case, is going to reject the argument and fail with an error. In clang, we have to explicitly declare which arguments are going to be transfer to the linker. Of course, the correct way to pass arguments to the linker is to use -Xlinker or -Wl but the Debian rebuild proved that these shortcuts are used. Two of these arguments are now forwarded:

  • -z keyword - r213198
  • -u Force symbol to be entered in the output file as an undefined symbol - r211756. This one fixed most of the haskell build failures. It fixed the most common issue that we had (701 occurrences but this does not mean that all these packages build fine now, some haskell-based package are failing later in the process)

New errors

Just like in other releases, new warnings are added in clang. With (bad) usage of -Werror by upstream software, this causes new build failures:

I also took the opportunity to add some further categorizations in the list of errors. Some examples:

Next steps

The Debile project being close to ready with Clément Schreiner's GSoC, we will now have an automatic and transparent way to rebuild packages using clang.

Conclusion

As stated, we can see a huge drop in term of number of failures over time:

Hopefully, Clang getting better and better, more and more projects adopting it as the default compiler or as a base for plugin/extension developments, this percentage will continue to decrease.
Having some kind of release goal with clang for Jessie+1 can now be considered as potentially reachable.

Want to help?

There are several things which can be done to help:

  • Point me common error patterns in the Not categorized list of errors to create new categories
  • Report and fix packages
  • As an upstream, integrate clang as part of your continuous integration system
  • Hack on cqa-scanlogs, the error detection tool to detect error patterns (example: Undetected error). This tool is used also for the regular rebuilds of the archive.
  • Improve clang.debian.net website

Acknowledgments

Thanks to David Suarez for the rebuilds of the archive, Arthur Marble and Alexander Ovchinnikov for their GSoC works and Nicolas Sévelin-Radiguet for the few fixes.

by Sylvestre at September 11, 2014 12:17 PM

September 08, 2014

OpenMP Runtime Project

New code release

We are excited to announce the next release of the Intel® OpenMP* Runtime Library at  openmprtl.org.  This release aligns with Intel® Composer XE 2013 SP1 Update 4, scheduled for release in summer of 2014.

New features

by mad\jlpeyton at September 08, 2014 08:17 PM

LLVM Blog

LLVM Weekly - #36, Sep 8th 2014

Welcome to the thirty-sixth 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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

The biggest news this week is of course undoubtedly the long-awaited release of LLVM/Clang 3.5. See the release notes for a full breakdown of what's changed.

Rhine, a Clojure-inspired Lisp with an LLVM JIT backend has been released (or at least, I wasn't aware of it before). There's plenty of discussion about it over at HN.

Intel have released a new version of their CilkPlus LLVM-basd compiler. This releases implements support for version 1.2 of Intel's Cilk Plus Language Extension Specification.

On the mailing lists

LLVM commits

  • LLVM gained a new alias analysis implementation, the CFL (Context-free language) alias analysis algorithm. When bootstrapping LLVM, this pass gives 7-8% NoAlias responses to queries that TBAA and BasicAA couldn't answer. r216970.

  • The old JIT has finally been removed. r216982.

  • FastISel gained the option to skip target-independent instruction selection. This is now used by AARch64, which uses target-dependent instruction selection only. r216947, r216955.

  • MCAnalysis has been removed. The code was judged to be buggy and poorly tested. r216983.

  • AArch64 gained a pass to try to remove redundant comparison operations. r217220.

  • FastISel has seen some spring cleaning. r217060.

Clang commits

  • VariantMatcher::MatcherOps was modified to reduce the amount of generated code. This reduces object size and compilation time. r217152.

  • Support for the 'w' and 'h' length modifiers in MS format strings was added. r217195, r217196.

  • A new warning is born. -Wunused-local-typedef will warn about unused local typedefs. r217298.

Other project commits

  • LLDB has gained initial support for 'type validators'. To quote the commit message, "Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light". r217277.

  • It is now possible to build libc++ on systems without POSIX threads. r217271.

  • A target.process.memory-cache-line-size option has been added to LLDB which changes the size of lldb's internal memory cache chunks read from the remote system. r217083.

by Alex Bradbury (noreply@blogger.com) at September 08, 2014 02:51 PM

September 01, 2014

LLVM Blog

LLVM Weekly - #35, Sep 1st 2014

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. 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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

As I mentioned in a previous issue, I am involved in the lowRISC projects to produce a fully open-source SoC. Just a quick reminder that we are hiring, and you have just over a week to get your application in.

The canonical home for this issue can be found here at llvmweekly.org.

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.

Quarks Lab have published a preview of SCAF, a Source Code Analysis Framework built on Clang. It promises a release soon.

The VMKit project website has this week been updated 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. The C++ AMP (Accelerated Massive Parallelism) compiler is of course based on LLVM and Clang, and can be found here.

On the mailing lists

  • Manuel Klimek has provided a quick run-down of the state of his work on Clang C++ refactoring tools. 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.

  • Robin Morisset has been working on optimisations for lowering of atomics and has asked for input on a fence elimination algorithm he's been thinking about. He has outlined two possible implementation routes he would like feedback on.

  • A discussion about improving llvm-objdump, kicked offed 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. 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.

  • 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. It's also worth reading this thread for an idea of what the new infrastructure might look like.

LLVM commits

  • The AArch64 backend learned about v4f16 and v8f16 operations, r216555.

  • The LLVM CMake build system now includes support for building with UndefinedBehaviourSanitizer. r216701.

Clang commits

  • The -fdevirtualize and -fdevirtualize-speculatively flags are now recognised (and ignored) for compatibility with GCC. r216477.

  • 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.

  • Support was added for capturing variable length arrays in C++11 lambda expressions. r216649.

Other project commits

  • LLDB gained documentation on its internal register numbering scheme. r216372.

  • LLDB is making progress towards AArch64 support. r216736.

by Alex Bradbury (noreply@blogger.com) at September 01, 2014 05:48 PM

August 25, 2014

LLVM Blog

LLVM Weekly - #34, Aug 25th 2014

Welcome to the thirty-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.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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

The third release candidate for LLVM/Clang 3.5 is now available. As ever, test it on your codebases and report any regressions.

Adrian Sampson has written a blog post about Quala, a tool for implementing pluggable type systems for C/C++ using Clang. The example type systems are a system allowing nullable and non-nullable pointers as well as an information flow tracking system. In the future, Adrian wants to connect type annotations to LLVM IR.

C++14 is now done. A quick look at the Clang C++14 implementation statusconfirms that Clang support is in pretty good shape.

Santiago Fernandez has been an intern on the .NET team at Microsoft this summer. In this MSDN Channel9 posting, Beth Massi interviews him about his work on using LLVM in the .NET native code generator.

The next Cambridge (UK) LLVM social will be held on Weds 27th August, 7.30pm.

On the mailing lists

  • There is a proposal to move the minimum supported Visual Studio version for compiling LLVM/Clang up to 2013 from 2012. LLVM/Clang 3.6 would be the first stable release with this requirement assuming there are no objections. With the introduction of C++11 features into the LLVM/Clang codebases, MSVC2012 support is troublesome due to a number of unsupported constructs. If this change would effect you negatively, now is the time to pipe up.

  • Richard Carback reports that two of his interns at Draper Laboratories have been working on resurrecting the LLVM C Backend, with source on Github. If this is to make it back into the mainstream repository, somebody will have to volunteer to maintain it which Richard has kindly done.

  • Diego Novillo has posted an update on his plans for supporting profile data from Perf in LLVM. He is now planning on keeping conversion to Perf's format out-of-tree. The current LLVM representation can be used as an exchange format, but Diego will be submitting a more compact representation for internal use.

  • Chris Bieneman has posted an RFC on removing static initializers for command line options. This would make it easier for LLVM clients like WebKit and Mesa. There is a lot of discussion about this proposal that I'm afraid I don't have time to summarise.

LLVM commits

  • X86 Haswell gained a detailed scheduling model. r215094, r215905, and more.

  • LLVM's code coverage mapping format gained extensive documentation. r215990.

  • FastISel for AArch64 saw yet more changes, this time optimisations for ADDS/SUBS emission and support for variable shifts. r216033, r216242.

  • The MIPS assembler gained support for .set arch=x. r215978.

  • The PeepholeOptimizer has been improved to take advantage of the recently added isRegSequence, isExtractSubreg, and isInsertSubreg properties. r216088, r216136, r216144.

  • A thread-model option has been added along with the 'single' option for lowering atomics on baremetal and single-threaded systems. r216182.

  • The gold plugin has been rewritten in order to fix bug 19901. r216215.

Clang commits

  • C++1y is now called C++14. r215982.

  • CGcall (code generation for function call) has been refactored. r216251.

Other project commits

  • The libcxx build and test system gained support for LLCM_USE_SANITIZER. r215872.

  • libcxxabi/libunwind now supports baremetal ARM. r216202.

by Alex Bradbury (noreply@blogger.com) at August 25, 2014 07:28 PM

August 18, 2014

LLVM Blog

LLVM Weekly - #33, Aug 18th 2014

Welcome to the thirty-third 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.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@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

The canonical home for this issue can be found here at llvmweekly.org.

News and articles from around the web

Binaries for LLVM/Clang 3.5RC2 are now available for testing. Try it on your codebases, and be sure to report any regressions.

LDC 0.14.0 has been released. LDC is an LLVM-based compiler for the D programming language. There's a mixture of new features and bug fixes, see the release notes for full details of what's changed.

Viva64, who sell the PVS-Studio static analyzer has written up their experiences of using the Clang static analyzer on the PVS-Studio codebase. It managed to find 12 issues which the blog author considers genuine bugs.

On the mailing lists

LLVM commits

  • FastISel for AArch64 will now make use of the zero register when possible and supports more addressing modes. r215591, r215597.

  • MIPS gained support for the .end, .end, .frame, .mask, and .fmask assembler directives. r215359.

  • ARM gained the MRS/MSR system instructions. r215700.

Clang commits

  • Documentation has been added describing how the Language options in .clang-format files works. r215443.

  • Prefetch intrinsics were added for ARM and AArch64. r215568, r215569.

  • The logic for the -include command line parameter is now properly implemented. r215433.

Other project commits

  • LLD now has initial support for ELF/AArch64. r215544.

  • UndefinedBehaviourSanitizer gained a returns-nonnull sanitizer. This verifies that functions annotated with returns_nonnull do return nonnull pointers. r215485.

  • A number of lldb tests now compile on Windows. r215562.

by Alex Bradbury (noreply@blogger.com) at August 18, 2014 12:07 PM