[LLVMdev] LLVM IR is a compiler IR

[Kenneth Uildriks]

On Wed, Oct 5, 2011 at 12:29 AM, Talin <viridia at gmail.com> wrote:

> On Tue, Oct 4, 2011 at 5:08 PM, Chris Lattner <clattner at apple.com> wrote:
>
>>
>> On Oct 4, 2011, at 4:56 PM, Talin wrote:
>>
>> > 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.
>>>
>>> I understand that the official goals of the LLVM project are carefully
>> limited. A large number of LLVM users are perfectly happy to live within the
>> envelope of what LLVM provides. At the same time, there are also a fair
>> number of users who are aiming for things that appear to be just outside
>> that envelope. These "near miss" users are looking at Java, at CLR, and
>> constantly asking themselves "did I make the right decision betting on LLVM
>> rather than these other platforms?" Unfortunately, there are frustratingly
>> few choices available in this space, and LLVM happens to be "nearest"
>> conceptually to what these users want to accomplish. But bridging the gap
>> between where they want to go and where LLVM is headed is often quite a
>> challenge, one that is measured in multiple man-years of effort.
>>
>>
>> I completely agree, and I'm really interested in LLVM improving to solve
>> these sorts of problems.  I'm not sure how this relates to Dan's email or my
>> response though.
>>
>> Here's my position in a nutshell: The kind of things that Dan wants LLVM
> to do should really be a separate sub-project from LLVM proper, built on top
> of LLVM. I think it's unrealistic to expect LLVM proper to adopt Dan's
> stated objectives - but at the same time, it would be a awful shame if there
> wasn't something that could meet his needs, since I think many people other
> than Dan would benefit from such a thing.
>
> For example, I don't expect that LLVM IR should suddenly become stable and
> usable as an archive format, but I think it entirely reasonable that someone
> could come up with a higher-level IR, translatable into LLVM IR, that does
> have those qualities. The fact that we have projects that convert JVM
> bytecode into LLVM IR is proof that such a thing is possible. (Except that
> any language implementer willing to live with the limitations of the JVM
> probably wouldn't be on this mailing list to begin with, but I digress.)
>
> The question I am interested in exploring is whether the goals of the "near
> miss" users of LLVM are similar enough to each other to be worth having a
> conversation about how to achieve those goals collaboratively, or whether it
> is better that we should each continue to struggle with our own problems
> individually.
>
> --
> -- Talin
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> As a would-be language implementer, I see a few choices:

JVM: Severe restrictions on generated code, no structs or stack objects or
pass-by-reference of stack values, heavy runtime that generated code must
run inside of, strict type hierarchy, very little control over optimization.
CLR: Lags behind the JVM on non-Microsoft platforms.  Also a heavy runtime.
 However, it has more flexibility in its generated code.
LLVM: Much, much more flexibility and optimization hooks than either JVM or
CLR, but with piecemeal GC support, ABI complications, portability issues,
JIT issues, and all the rest.

>From what I can tell, there's a *huge* gap between LLVM on the one hand and
JVM/CLR on the other... and having *something* in that gap would
allow/encourage the development of a huge array of useful languages and
runtimes that don't exist right now.

It seems far more plausible to me for LLVM to evolve into that "something"
than for the JVM or CLR to do so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111005/e9ab8da0/attachment.html>