Home

SIGPLAN's first Programming Languages Software Award goes to LLVM

ACM Press Release:

The ACM Special Interest Group on Programming Languages (SIGPLAN) today presents its first-ever Programming Languages Software Award to Chris Lattner of Apple Inc. for his design and development of the Low Level Virtual Machine (LLVM), a compiler infrastructure that has been quickly adopted by a wide array of industry and academic organizations. Since LLVM’s release as an open source compiler infrastructure in October 2003, companies including Apple, Adobe, and Cray have incorporated it into their commercial products, reflecting its simplicity, flexibility, and versatility.

By bashyal at 2010-06-08 21:18 | Cross language runtimes | General | other blogs | 17187 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Open source projects are

Open source projects are also evaluating LLVM: FreeBSD is moving away from GCC into clang/LLVM (see slide 15 for some performance comparisons).

By vieiro at Wed, 2010-06-09 06:56 | login or register to post comments

Mature?

According to those slides, it only compiler ok on AMD, and somewhat on i386. Doesn't mean it isn't a good effort, but mature? My guess is it is at least two to three years away from that.

By marco at Wed, 2010-06-09 14:21 | login or register to post comments

What's mature?

I read them as saying that clang/LLVM is mature, not that clangBSD is. For C and Objective-C, that seems like a fair claim. For C++, it's... er... (pre)mature. :-)

By Paul Snively at Wed, 2010-06-09 16:22 | login or register to post comments

Growing up fast

As for C++ support, Clang/LLVM not only builds itself, but builds all of Boost and passes 100% of Boost's tests. Apparently neither GCC nor Visual Studio pass all of those tests, despite Boost's ample compiler-specific workarounds. The C++ support isn't production quality yet, but it's almost there and moving quickly.

By Bret Victor at Fri, 2010-06-11 03:44 | login or register to post comments

The amd64 and i386 kernels

The amd64 and i386 kernels boot multiuser , they say. And "All of userland (plus the LLVM/clang itself) compiles and runs ok except for libobjc". That's quite mature, I'd say!

By vieiro at Wed, 2010-06-09 17:10 | login or register to post comments

import of clang/LLVM into FreeBSD HEAD

Clang imported into head

Clang will be enabled to be built on amd64/i386/ppc by default and disabled
everywhere else.

Also in the BSDTalk interview(bsdtalk191) they mention that clang would be default for FreeBSD 9.0, at least on Intel.

By bashyal at Fri, 2010-06-11 15:52 | login or register to post comments

Licensing may be a factor in that.

Indeed. It's an interesting question how much of the motivation for that is license-based as compared to technology-based. GCC is a big critical lump of GPL'ed code in the middle of FreeBSD's primarily-BSD-licensed system, and I can easily imagine that they might consider that unfortunate.

Likewise, Apple's support of LLVM appears heavily driven by a desire to avoid the GPL, even if it might be equally driven by technical merits.

By Brooks Moses at Wed, 2010-06-09 21:48 | login or register to post comments

Re: Licensing may be a factor in that.

"GCC 4.2.1/Binutils 2.15 and no updates allowed" on slide 3 definitely implies they're staying away from GPLv3. If they wanted C++0x and newer CPU support then moving to a newer GCC would solve that, so the license is probably the issue.

By Jonathan Wakely at Thu, 2010-06-10 09:20 | login or register to post comments

Licensing seems to be the main issue

From the abstract of that talk:

FreeBSD currently uses gcc as its system compiler. Because of a political decision on GPLv3 we are stuck with version 4.2.1.

...

Unfortunatelly gcc switched to GPLv3 which is incompatible with FreeBSD, as decided by core, thus we are stuck with quite old gcc version 4.2.1. There are other problems with gcc, mostly awkward dealing with upstream. A very similar story goes on with the assembler and linker.

By bashyal at Fri, 2010-06-11 16:08 | login or register to post comments

Now there's a debugger too

The LLDB Debugger

LLDB is a next generation, high-performance debugger. It is built as a set of reusable components which highly leverage existing libraries in the larger LLVM Project, such as the Clang expression parser and LLVM disassembler.

Nice set of goals:

The current state of the art in open source debuggers are that they work in the common cases for C applications, but don't handle many "hard cases" properly. For example, C++ expression parsing, handling overloading, templates, multi-threading, and other non-trivial scenarios all work in some base cases, but don't work reliably.

The goal of LLDB is to provide an amazing debugging experience that "just works". We aim to solve these long-standing problems where debuggers get confused, so that you can think about debugging your problem, not about deficiencies in the debugger.

By bashyal at Wed, 2010-06-09 14:41 | login or register to post comments

And a static analyzer and a

And a static analyzer and a tool for "automatically generating tests that achieve high coverage on a diverse set of complex and environmentally-intensive programs".

By vieiro at Wed, 2010-06-09 17:16 | login or register to post comments

Two gripes with LLVM

LLVM is pretty good. I use it in the runtime for XL, XLR, and I have a lot to say in its favor: quality of generated code, stability, ease of programming.

There are also two things that I really don't like from an engineering point of view:

1) No backward compatibility. That's intentional, see this thread. This makes it unnecessarily hard to write code that works with both llvm 2.6 and llvm 2.7.

2) Lazy error checking and nonexistent error handling. Errors are detected late rather than early, and reported with 'assert'. This may be acceptable for users like Clang, it's dangerous for a runtime. And it makes it really hard to do stuff like exploring compilation strategies with genetic algorithms.

But again, these drawbacks are relatively minor compared to what you get. LLVM opens up interesting possibilities, like optimizing code on the fly depending on the target.

By Christophe de Dinechin at Sun, 2010-06-20 11:03 | login or register to post comments

RE: Two gripes with LLVM

Yeah, I would have to agree - the constant API flux is extremely annoying. Upgrading between versions can be substantial work.

Also, the lack of stable branches / "dot releases", means I have to wait > 6 months for bug fixes (yes, llvm has bugs.)

But overall, it's a great compiler infrastructure.

By strog at Sun, 2010-07-04 18:54 | login or register to post comments

Perhaps worth mentioning

Perhaps worth mentioning both Chris Lattner and his adviser, Vikram Adve, have done a lot of other good work as well. E.g., I just bumped into some of their papers on memory layout, and perhaps of more interest to LtU, Vikram's group is currently working on Deterministic Java (where I think a big part of the idea is to tag data structures with region types to guarantee separation).

By lmeyerov at Tue, 2010-07-06 19:16 | login or register to post comments