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...
On Oct 5, 2011, at 1:17 AM, Renato Golin wrote:> 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.Hi Renato, I think you're overreacting here. There is nothing about OpenCL, RenderScript, or VMKit that requires LLVM IR be used like a Platform, as I defined it in my first paragraph. I'm aware that some people would like to use LLVM IR as a Platform, and I'm saying that there are important high-level considerations to make before doing so, and my impression is that there is little discussion of issues I consider important. Possibly it's too late for some though, and possibly people are getting too caught up on the thorny ABI issues and missing my broader ideas. Dan
On Oct 5, 2011, at 1:17 AM, Renato Golin wrote:> 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.Hi Renato, I think you're overreacting here. There is nothing about OpenCL, RenderScript, or VMKit that requires LLVM IR be used like a Platform, as I defined it in my first paragraph. I'm aware that some people would like to use LLVM IR as a Platform, and I'm saying that there are important high-level considerations to make before doing so, and my impression is that there is little discussion of issues I consider important. Possibly it's too late for some though, and possibly people are getting too caught up on the thorny ABI issues and missing my broader ideas. Dan
On 5 October 2011 16:18, Dan Gohman <gohman at apple.com> wrote:> I think you're overreacting here. There is nothing about OpenCL, RenderScript, > or VMKit that requires LLVM IR be used like a Platform, as I defined it in my > first paragraph. I'm aware that some people would like to use LLVM IR as a > Platform, and I'm saying that there are important high-level considerations > to make before doing so, and my impression is that there is little discussion of > issues I consider important.Hi Dan, I probably am. And that got in the way of highlighting the real issue. As Kenneth just highlighted, there is a gap, and people are trying to fill that gap. I personally prefer to use LLVM for that job, instead of Java bytecode, and it seems many people feel the same. So, let's separate the issues here: 1) LLVM IR is a compiler IR, nothing else, nor should be. I agree with David, this is not a bad thing. Case closed. 2) Has LLVM the potential to fill that gap via other routes? Can LLVM do (one day) what you wanted it to do today? A higher level representation for light-weight JITs, a rich type-system for complex linkage of higher languages, special semantics for special purposes, etc. Today, LLVM IR is NOT portable, so why worry about the portability of DSLs around it? OpenCL rep. can be different (in syntax, and semantics) from C++ rep., but it should be similar to RenderScript rep. If you want to link CL and C++ reps, lower them to LLVM IR, or use the common subset. -- cheers, --renato http://systemcall.org/
Renato Golin <rengolin <at> systemcall.org> writes:> > 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. >I thought I'd offer the perspective from another project that uses LLVM and needs to be cross platform, Emscripten. Emscripten takes LLVM assembly and compiles that into JavaScript. We have had to implement a lot of hacks to work around portability issues in LLVM assembly, but overall *un*-optimized assembly is not that hard to get working. Optimized assembly is a different story, but since the target language is JS that isn't too much of a concern (we can do standard compiler optimizations after translation to JS, using Closure Compiler and other tools, with good results - since it is then done at the level of JS). Overall LLVM has been extremely useful for Emscripten because it is very well documented and developed and has a friendly community. If LLVM assembly could be portable (no hardcoded structure indexes, no hardcoded sizes, etc. etc.) then that would be much better for Emscripten obviously. But I think that even without that, LLVM assembly is already very usable for some types of projects that require portability. So, given how difficult portability is to get right, and that it typically requires compromises elsewhere, my recommendation would be to consider such things very carefully. I'd love for there to be some way to generate portable assembly, but I am not sure LLVM should try to do that - it does other things, and it does them extremely well. - azakai