LLVM IR is a compiler IR

http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html

by pcwalton • 15 years ago

118 41 15 years ago

lists.cs.uiuc.edu

protomyth• 15 years ago

quick link to Chris Lattner's response: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/0437...

icefox• 15 years ago

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

przemoc2• 15 years ago

Why copy-paste? (Well, I think I know why...) Should we do the same with all messages from ML now? Just use normal ML UI, like gmane, I provided link to earlier. If you need direct one to Chris' mail, it would be:

http://thread.gmane.org/gmane.comp.compilers.llvm.devel/4376...

Actually I'm not sure why this particular response was pointed out, as it is not perfect rebuttal. It's almost always better to even only skim whole thread than be picky about which mail to read carefully, as you'll always miss something then.

mdda2• 15 years ago

LLVM IR = "Low Level Virtual Machine" (originally written to be a replacement for the existing code generator in the GCC stack) "Intermediate Representation" (virtual machine language, prior to being crunched into actual machine code).

reduxredacted• 15 years ago

I hope I'm not the only one here upvote your comment simply because you decompressed IR into Intermediate Representation.

I like to read about LLVM and some of the things that are a bit (ok, in a lot of cases, way) above what I do day-to-day, except that it's sometimes taken for granted that the readers know the acronym/reference. I read the whole article and I understood what it was referring to, but for the life of me I couldn't land on the two words because IR in my world is always infrared.

mdda2• 15 years ago

Somewhat infuriatingly, my simple IR->"Intermediate Representation" was my highest ever scoring comment, and the one that pushed me over 500...

Lesson learned : Make something people want.

nknight5• 15 years ago

I was already getting a bad feeling about LLVM recently, and this thread kind of cements that.

Everybody seems to have a different (sometimes radically different) idea of what LLVM is for. That can't be good for making progress, and it's definitely not good for guys like me wondering if LLVM is a sane choice for a project.

bsiemon• 15 years ago

LLVM is a square peg. If your project needs a square shaped peg then it will do amazing things for you. On the other hand if you want it to do circle shaped things you will feel the pain.

nknight5• 15 years ago

Thanks for the fortune-cookie wisdom. That tells no one anything. We don't have square pegs or round holes, we have complex engineering problems to solve, and LLVM's complex shape is obscured by a community that doesn't agree on its shape, so we have no way to tell if it fits our holes.

eliben• 15 years ago

Don't take it too far. For purposes it was designed to serve, LLVM is great, best in its class. If your project is something that could benefit from LLVM, then by all means use it. If it isn't, then don't. As simple as that.

Many corporations (most of all Apple) bet millions of $$$s in resources on projects that depend on LLVM, so don't worry too much.

nknight5• 15 years ago

And what purpose was it designed to serve? That's exactly the problem I'm alluding to -- the LLVM developers don't even agree amongst themselves, so how am I supposed to know?

chc3• 15 years ago

I don't see any disagreement along those lines in the thread under discussion here. The LLVM project is quite clear (it says so on its homepage!) that it is not making a typical virtual machine along the lines of the JVM. What are you talking about? This sounds like completely random and out-of-context FUD.

nknight5• 15 years ago

And yet it says it might be used to build such, and this thread contains disagreement amongst the developers of the original purposes and the meaning of "virtual machine".

I'm just a developer who has looked into LLVM in the recent past for possible use in cross-platform projects and come away more confused than enlightened, and this thread just magnified it. Interpreting that as "FUD" is wildly unhelpful.

przemoc2• 15 years ago

Whole thread in much more readable UI, w/o problems of terrible 90s ML web stuff.

http://thread.gmane.org/gmane.comp.compilers.llvm.devel/4376...

ot• 15 years ago

These are exactly the reasons why I am very skeptical about pNaCl. I've done some work with LLVM and I've been stuck on some of these points: the IR is target-dependent, the function call conventions are basically those of C, the optimization passes and the code generator are extremely slow when compared to an ad-hoc JIT (this would mean terrible startup time for web applications). And, furthermore, the size of the bitcode is still enormous, comparable to the generated machine code or even worse (think about the size of C++ binaries).

I still think that LLVM is an incredibly great project, it brought compiler infrastructure to 2010s. But it is designed to be a static compiler framework, it hardly fits other purposes (think Unladen Swallow, don't know about Rubinius).

erichocean4• 15 years ago

LLVM is being used as a JIT in Open Shading Language, a DSL for advanced 3D renderers. The JIT + resulting code was so fast, the OSL team dropped their batch rendering API altogether. (The resulting shaders are 25% faster than the hand-coded C language shaders they replaced.)

Currently, the LLVM JIT-powered OSL is now responsible for 100% of the shading duties at Sony Pictures Imageworks. I'd say that's a resounding success for LLVM as a JIT.

ajross2• 15 years ago

I'm not sure how that refutes the point. OSL is a shading language, that's an environment dominated by runtime execution time, not startup latency. So it might be a "JIT" in that there's no stored binary, but it's performance criteria are much (much!) closer to those of gcc or clang than to, say, a JVM or script interpreter.

And, like the post said: LLVM IR is a compiler IR. It's a great fit here.

modeless• 15 years ago

Shaders compile once and execute millions of times. Most code on the Web code compiles once and executes zero, one, or a small number of times. He's saying LLVM is less suited to the latter case because it compiles slowly (though the resulting code is fast).

azakai• 15 years ago

> And, furthermore, the size of the bitcode is still enormous, comparable to the generated machine code or even worse (think about the size of C++ binaries)

Actually I believe the bitcode is much larger than C or C++ binaries. The issue is that LLVM bitcode is basically a statically-typed language, lower than C. So for example to convert a pointer from one type to another you need to do an explicit cast (using an LLVM 'bitcast' operation). However, when you compile all the way down to native code, you have no need for such niceties and you just copy the value. So the bitcode ends up significantly larger than the native code would be, in order to maintain static typing correctness. There are some other issues as well.

LLVM bitcode was not designed for size, it's - exactly as the article says - just a compiler IR. So it isn't designed for size, portability, JITing speed, or anything like that. Trying to morph it into those is problematic and worse, may lead to compromises in LLVM's core goals. Which would be a shame since LLVM is a damn good compiler IR!

hannibalhorn• 15 years ago

In the case of pNaCl, startup time and code size issues could easily be addressed by providing the architecture specific versions server side. Either the developer provides those versions as well, or a third party web service could do the translation.

The LLVM IR format could just be the developer target so that things are actually portable, and we don't wind up in a situation where 90% of the NaCl plugins are x86-only.

m0wfo2• 15 years ago

Just as a naive consumer of its facilities, I find LLVM produces binaries from C and ObjC code which are smaller and faster than their GCC equivalents. I'm attempting to write my own front-end as well, which is easier than I had expected. I don't care what the black box does, c.f. "The user doesn't care"(TM).

ori_b• 15 years ago

GCC is still marginally smaller and faster: http://www.phoronix.com/scan.php?page=article&item=gcc_4...

m0wfo2• 15 years ago

IMHO, YMMV, etc. Oh man it's so easy to wind up HN kids with anecdotes.

wmf• 15 years ago

No one is complaining about using LLVM they way it's supposed to be used. The problem is that LLVM has been promoted for use cases that it totally sucks for (JIT, portable bitcode).

LLVM IR is a compiler IR

Related Stories