On Tue, Oct 4, 2011 at 4:19 PM, Chris Lattner <clattner at apple.com> wrote:> 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. > > I understand that the official goals of the LLVM project are carefullylimited. 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. -Chris> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111004/52976000/attachment.html>
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. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111004/1ab560a0/attachment.html>
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 todo 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111004/1917e64d/attachment.html>