[LLVMdev] LLVM IR is a compiler IR

Chris Lattner
Tue, 04 Oct 2011 23:19:54 -0000

On Oct 4, 2011, at 11:53 AM, Dan Gohman wrote:
> In this email, I argue that LLVM IR is a poor system for building a
> Platform, by which I mean any system where LLVM IR would be a
> format in which programs are stored or transmitted for subsequent
> use on multiple underlying architectures.

Hi Dan,

I agree with almost all of the points you make, but not your conclusion.  Many
of the issues that you point out as problems are actually "features"
that a VM like Java doesn't provide.  For example, Java doesn't have
uninitialized variables on the stack, and LLVM does.  LLVM is capable of
expressing the implicit zero initialization of variables that is implicit in
Java, it just leaves the choice to the frontend.

Many of the other issues that you raise are true, but irrelevant when compared
to other VMs.  For example, LLVM allows a frontend to produce code that is ABI
compatible with native C ABIs.  It does this by requiring the frontend to know a
lot about the native C ABI.  Java doesn't permit this at all, and so LLVM
having "this feature" seems like a feature over-and-above what
high-level VMs provide.  Similiarly, the "conditionally" supported
features like large and obscurely sized integers simply don't exist in these
VMs.

The one key feature that LLVM doesn't have that Java does, and which cannot
be added to LLVM "through a small matter of implementation" is
verifiable safety. Java bytecode verification is not something that LLVM IR
permits, which you can't really do in LLVM (without resorting to techniques
like SFI).

With all that said, I do think that we have a real issue here.  The real issue
is that we have people struggling to do things that a "hard" and see
LLVM as the problem.  For example:

1. The native client folks trying to use LLVM IR as a portable representation
that abstracts arbitrary C calling conventions.  This doesn't work because
the frontend has to know the C calling conventions of the target.

2. The OpenCL folks trying to turn LLVM into a portable abstraction language by
introducing endianness abstractions.  This is hard because C is inherently a
non-portable language, and this is only scratching the surface of the issues.
To really fix this, OpenCL would have to be subset substantially, like the EFI C
dialect.

> LLVM isn't actually a virtual machine. It's widely acknoledged that
the
> name "LLVM" is a historical artifact which doesn't reliably
connote what
> LLVM actually grew to be. LLVM IR is a compiler IR.

It sounds like you're picking a very specific definition of what a VM is.
LLVM certainly isn't a high level virtual machine like Java, but that's
exactly the feature that makes it a practical target for C-family languages.  It
isn't LLVM's fault that people want LLVM to magically solve all of
C's portability problems.

-Chris