[LLVMdev] LLVM IR is a compiler IR

[Chris Lattner]

On Oct 4, 2011, at 4:42 PM, Renato Golin wrote:
> 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.
> 
> Chris,
> 
> This is a very simplistic point of view, and TBH, I'm a bit shocked.

I'm sorry, I didn't mean to be offensive.

> 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.

I'm not sure what you're getting at here.  My email was not intended to say that I'm not interested in LLVM improving - quite the contrary.  My email was to rebut Dan's implicit claim that PNaCL and using LLVM as a portable IR is never going to work.  I'm arguing in the "opencl" and "pnacl" folks favor :)

That said, I'm trying to also inject realism.  C is an inherently hostile language to try to get portability out of.

> 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.

I'm not sure what point you're trying to make here.  We all know that LLVM sucks, fortunately lots of people seem to be motivated to help make it better :)

> 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...

I think that we're pretty strongly miscommunicating...

-Chris