LLVM Project News and Details from the Trenches

Wednesday, April 14, 2010

Extensible Metadata in LLVM IR

A common request by front-end authors is to be able to add some sort of metadata to LLVM IR. This metadata could be used to influence language-specific optimization passes (for example, Type Based Alias Analysis in C), tag information for a custom code generator, or pass through information to link time optimization. LLVM 2.7 provides first-class support for this, and has switched debug information over to use it (improving debug info!).

While the details of this feature can be found in the LLVM Language Reference manual, sometimes it is hard to distill the big picture from the low-level details. This post tries to fill the gap by explaining some history, motivation and example use cases for this new LLVM 2.7 feature.

This post was written by Devang Patel and myself.

Friday, April 9, 2010

Intro to the LLVM MC Project

The LLVM Machine Code (aka MC) sub-project of LLVM was created to solve a number of problems in the realm of assembly, disassembly, object file format handling, and a number of other related areas that CPU instruction-set level tools work in. It is a sub-project of LLVM which provides it with a number of advantages over other compilers that do not have tightly integrated assembly-level tools.

This blog post talks about how the MC project evolved, describes a few different aspects of it , talks about the improvements/capabilities it brings to LLVM, and finishes off with the current status of the project.

Wednesday, April 7, 2010

ARM Advanced SIMD (NEON) Intrinsics and Types in LLVM

LLVM now supports all the intrinsic functions defined by ARM for the Advanced SIMD (aka "NEON") instruction set, but if you are migrating from GCC to LLVM, there are some implementation differences that you may encounter. LLVM follows ARM's specification of the standard NEON types more closely than GCC. It is also more strict about checking types of arguments to the NEON intrinsics.


This post describes the NEON-related differences between LLVM and GCC and gives a few examples of how to adapt your code to work with LLVM.


What's wrong with this code?

A user on IRC sent me this interesting KLEE example today, which I thought was cute enough I should post it.

If you aren't familiar with it, KLEE is a tool for symbolic execution of LLVM code. It is way too complicated to explain here, but for the purposes of this example all you need to know is that it tries to explore all possible paths through a program.


Monday, April 5, 2010

Amazing feats of Clang Error Recovery

In addition to parsing and generating machine code for your source files when valid, a compiler frontend's job is also to detect invalid code and give you a hint that explains what is wrong so you can fix the problem. The bug could either be straight-up invalid (an error) or could just be something that is legal but looks really dubious (a warning). These errors and warnings are known as compiler 'diagnostics', and Clang aims to go above and beyond the call of duty to provide a really amazing experience.

After the break, we show some examples of areas where Clang tries particularly hard. For other examples, the Clang web page also has a page on diagnostics and Doug showed how Clang diagnoses two-phase name lookup issues in a prior blog post.

Update: Other people are starting to compare their favorite compiler. Here's the OpenVMS Compiler. Email Chris if you have a comparison you want posted.