All,<div><br></div><div>I should have chimed in earlier, but have been working on two more side-channel variants of this conversation.</div><div>At the beginning the PNaCl team was strongly pushing for trying to keep platform ABI compatibility on all</div>
<div>platforms while taking one portable bitcode stream as input.  During the discussions we've had over the past few</div><div>weeks it became obvious that that is simply not tractable, and we're trying to work in a slightly different direction</div>
<div>that meets PNaCl's needs.</div><div><br></div><div>PNaCl needs to have one bitcode representation that can be lowered to efficient ABIs on all target platforms.</div><div>We're not constrained to have to use the exact ABI that trusted code would on each of the platforms, however.</div>
<div>For reasons of portability we've already eliminated long double support (or made it equivalent to double if you prefer).</div><div>And we're currently proposing to use the platform ABIs, except that structure arguments (including unions, bitfields, etc.)</div>
<div>are always passed in memory.  With this set of caveats we think we can meet our objectives for at least x86-32,</div><div>x86-64, and ARM.  The remaining complexity is making byval usable on all platforms so that we can have one representation.</div>
<div>Of course we'd like community input on the issues we've overlooked.</div><div><br></div><div>There are other issues of compatibility that still keep us awake at night, of course, and I hope the next developers'</div>
<div>conference will give us the chance to wrangle with some of those.</div><div><br></div><div>David</div><div><br><div class="gmail_quote">On Tue, Oct 4, 2011 at 5:19 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Oct 4, 2011, at 4:42 PM, Renato Golin wrote:<br>
> On 5 October 2011 00:19, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br>
>> 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.<br>

> (...)<br>
>> 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.<br>

> (...)<br>
>> 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.<br>

><br>
> Chris,<br>
><br>
> This is a very simplistic point of view, and TBH, I'm a bit shocked.<br>
<br>
</div>I'm sorry, I didn't mean to be offensive.<br>
<div class="im"><br>
> JIT, "the native client folks", "the openCL folks" are showing how<br>
> powerful LLVM could be, if it was a bit more accommodating. Without<br>
> those troublesome folks, LLVM is just another compiler, like GCC, and<br>
> being completely blunt, it's no better.<br>
<br>
</div>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 :)<br>

<br>
That said, I'm trying to also inject realism.  C is an inherently hostile language to try to get portability out of.<br>
<div class="im"><br>
> The infrastructure to add new passes is better, but the number and<br>
> quality of passes is not. It's way easier to create new back-ends, but<br>
> the existing number  and quality, again, no better. The "good code" is<br>
> suffering a diverse community, large codebase and company's interests,<br>
> which is not a good forecast for code quality. It's not just the IR<br>
> that has a lot of kludge, back-ends, front-ends, dwarf emitter,<br>
> exception handling, etc., although some nicer than GCC, it's not<br>
> complete nor accurate.<br>
<br>
</div>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 :)<br>
<div class="im"><br>
> If you want to bet on a "fun community" to drive LLVM, I don't think<br>
> you'll go too far. And if you want to discard the OpenCL, JIT and<br>
> NativeClient-style community, well, there won't be much of a community<br>
> to be any fun...<br>
<br>
</div>I think that we're pretty strongly miscommunicating...<br>
<span class="HOEnZb"><font color="#888888"><br>
-Chris<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>