[LLVMdev] LLVM IR is a compiler IR

Renato Golin rengolin at systemcall.org
Tue Oct 4 16:42:07 PDT 2011

On 5 October 2011 00:19, Chris Lattner <clattner at apple.com> wrote:
> 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.
> 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.


This is a very simplistic point of view, and TBH, I'm a bit shocked.

Having a "nicer codebase" and "friendlier community" are two strong
points for LLVM against GCC, but they're too weak to migrate people
from GCC to LLVM.

JIT, "the native client folks", "the openCL folks" are showing how
powerful LLVM could be, if it was a bit more accommodating. Without
those troublesome folks, LLVM is just another compiler, like GCC, and
being completely blunt, it's no better.

The infrastructure to add new passes is better, but the number and
quality of passes is not. It's way easier to create new back-ends, but
the existing number  and quality, again, no better. The "good code" is
suffering a diverse community, large codebase and company's interests,
which is not a good forecast for code quality. It's not just the IR
that has a lot of kludge, back-ends, front-ends, dwarf emitter,
exception handling, etc., although some nicer than GCC, it's not
complete nor accurate.

If you want to bet on a "fun community" to drive LLVM, I don't think
you'll go too far. And if you want to discard the OpenCL, JIT and
NativeClient-style community, well, there won't be much of a community
to be any fun...

If you want to win on the code quality battle, while working for a big
company, good luck. Part of the GCC community's grunts are towards
companies trying to push selfish code in, and well, their reasons are
not all without merit.

I didn't see people looking for a magic wand on these discussions so far...



More information about the llvm-dev mailing list