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. 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... -- cheers, --renato http://systemcall.org/
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
All, I should have chimed in earlier, but have been working on two more side-channel variants of this conversation. At the beginning the PNaCl team was strongly pushing for trying to keep platform ABI compatibility on all platforms while taking one portable bitcode stream as input. During the discussions we've had over the past few weeks it became obvious that that is simply not tractable, and we're trying to work in a slightly different direction that meets PNaCl's needs. PNaCl needs to have one bitcode representation that can be lowered to efficient ABIs on all target platforms. We're not constrained to have to use the exact ABI that trusted code would on each of the platforms, however. For reasons of portability we've already eliminated long double support (or made it equivalent to double if you prefer). And we're currently proposing to use the platform ABIs, except that structure arguments (including unions, bitfields, etc.) are always passed in memory. With this set of caveats we think we can meet our objectives for at least x86-32, x86-64, and ARM. The remaining complexity is making byval usable on all platforms so that we can have one representation. Of course we'd like community input on the issues we've overlooked. There are other issues of compatibility that still keep us awake at night, of course, and I hope the next developers' conference will give us the chance to wrangle with some of those. David On Tue, Oct 4, 2011 at 5:19 PM, Chris Lattner <clattner at apple.com> wrote:> 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111004/8774bd9f/attachment.html>
On 5 October 2011 01:19, Chris Lattner <clattner at apple.com> wrote:> 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 :)Hi Chris, Ok, I think I (now) get your drift. Let's restart the conversation, then. ;) If I got it right this time, from your point of view, Dan's arguments are not accurate because IR never intended to be anything else anyway. PNaCl, OpenCL, RenderScript, Java-like VMs were aggregated over time and tried to use IR for what it was not designed to be. I completely agree with you in that one. If I'm not mistaken, JIT was never intended to be portable, but to test IR during a time back-ends were not stable enough. IR was never intended to cover ABI issues, complex type system, endianness of the read/write, etc. In effect, IR was never intended to be completely language/target agnostic. Again, I completely agree on that one. But there is a subliminal context that I don't think people understand, and that was my point. Communities are powerful things. It takes a while to create, but once you have it, it has a life of its own. For the community, it doesn't matter much what were the original goals of LLVM, just what you can do with it, now. LLVM is the *only* compilation infrastructure I know that is flexible and extensible enough to allow people to do such radical things in radically different ways. In a nutshell, Chris, you are a victim of your own success. If LLVM wasn't that flexible, people wouldn't stretch it that much, and you wouldn't have those problems. LLVM's community is strong, active and passionate. But OpenCL folks will be passionate about adding OpenCL features, and so on and that creates tension (and I understand the defensive position you have always been, protecting LLVM's integrity). But if you read in between the lines of what people are saying (and what I heard over and over during the Euro-LLVM), people are skeptical of the portability issue. Almost everyone, including experienced compiler engineers, comes to LLVM thinking the IR is portable. So, either we're all doing the wrong advertising of what LLVM really is, or we're not doing our jobs right. I'm now reading David Sehr's answer (and John's reply) and I think we're still missing the point. David listed the hacks he had to do to make it somewhat portable. I've listed (mostly last year) the hacks we had to do to implement the EDG bridge. Talin keeps reminding us what he has to do to work on his compiler. James wrote his own bytecode language on top of IR. If LLVM IR is not portable, and never will be, that's fine. I can live with that. But ignoring the crowd is not wise. I'm not saying you guys should implement a higher-level IR or change the current IR to fit to everyone's needs, that would be madness. What I'm asking is simply that you stop ignoring the fact that there is a problem (that lots of people want more portable IR) and that the solution is NOT to kludge it into the current IR. When people show hacks, don't say "excellent! problem solved". When people ask for portability solutions, don't recommend kludges, or "do like clang". Encourage people to contribute to portability, and be willing to accept such contributions even if that generates a bit more work to get it through than a kludge. -- cheers, --renato http://systemcall.org/ PS: I hope to have gotten it right this time, neither were meant as rants...
Chris Lattner <clattner at apple.com> writes:> That said, I'm trying to also inject realism. C is an inherently > hostile language to try to get portability out of.Aren't there (at least) two different aspects here? One is the source language. C is not portable. There's nothing LLVM can do to fix that. However, other HLLs are portable. What can LLVM do to help them? The other aspect is the ABI. Right now LLVM pretty much assumes a C-like ABI. That's only necessary for some C-derived languages. Fortran, for example, has no defined ABI so the compiler is free to do whatever it pleases. Fortran objects are not interchangeable among compiler vendors and users are perfectly fine with that, though often us compiler developers are not. :) So to me this seems like a language issue and an ABI issue, neither one of which need be tied directly to LLVM. That said, I think creating a portable LLVM IR is a huge project (much bigger than many people realize) and in the end, I don't think there's much to be gained. A portable IR built on top of LLVM makes more sense to me. Anyone interested in that should check read up on projects like ANDF that produced volumes of papers on what's required. -Dave