<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 31, 2013 at 11:55 PM, Travis Cross <span dir="ltr"><<a href="mailto:tc@travislists.com" target="_blank">tc@travislists.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 2013-07-30 22:11, Eli Bendersky wrote:<br>
> we've published an initial version of the PNaCl bitcode reference<br>
> manual online -<br>
> <a href="http://www.chromium.org/nativeclient/pnacl/bitcode-abi" target="_blank">http://www.chromium.org/nativeclient/pnacl/bitcode-abi</a>. The PNaCl<br>
> bitcode is a restricted subset of LLVM IR.<br>
><br>
> Any comments would be most welcome.<br>
<br>
Hi Eli,<br>
<br>
I appreciate you for opening the process for input and comments. One<br>
question stood out to me while reading the document:<br>
<br>
The document [1] indicates that only the 'ccc' calling convention will<br>
be supported. The LLVM documentation [2] prominently notes that,<br>
"tail calls can only be optimized when [fastcc], the GHC or the HiPE<br>
convention is used." Further, I notice that the document includes<br>
"call" but not "tail call" in the list of supported instructions.<br>
<br>
Do I understand correctly that this means that reliable tail call<br>
optimization will not be possible under PNaCL as currently imagined?<br></blockquote><div><br></div><div>Not at all. The tail call elimination pass runs during mid-level optimizations, before we strip calling conventions for PNaCl ABI stabilization. The "tail" marker on calls is not forbidden in PNaCl. However, it would be fair to say that we didn't invest a lot of effort into making sure TCO works in all cases because TCO support for C and C++ in LLVM is very rudimentary. For example, in LLVM 3.3 (the version the current preview of PNaCl is based on), this is the implementation of AllocaMightEscapeToCalls:</div>
<div><br></div><div><div>static bool AllocaMightEscapeToCalls(AllocaInst *AI) {</div><div> // FIXME: do simple 'address taken' analysis.</div><div> return true;</div><div>}</div></div><div><br></div><div>Michael Gottesman (+CC) improved this a couple of weeks ago - this area is still work in progress. While we'll be happy to have other languages target PNaCl, our current focus is on C and C++. Also see below.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
That would be a real shame. Languages such as Scheme, Haskell,<br>
Erlang, and Lua require tail call optimization. Working around the<br>
lack of TCO with trampolines degrades performance, requires a major<br>
reworking of the compiler front-end, and is ugly. Such hacks really<br>
shouldn't be needed in 2013, particularly when LLVM already went to<br>
the trouble of supporting TCO for exactly these good reasons.<br>
<br>
The JVM made this mistake in its byte code and many groups such as the<br>
Clojure and Scala communities have been clamoring for years to get TCO<br>
into the JVM. ECMAScript has this error as well, but it's forgivable<br>
as Javascript wasn't originally intended to be, as it is now, a<br>
compiler target.<br>
<br>
Indeed, I believe much of the enthusiasm for (P)NaCL stems from the<br>
hope that we'll finally be able to compile arbitrary languages for the<br>
browser without being unduly hampered or constrained. Without TCO the<br>
excitement here would be diminished. Functional programming languages<br>
would be kneecapped by the bytecode.<br>
<br>
If my understanding above is correct, how can we get PNaCL to support<br>
a sufficiently general calling convention to make TCO possible?<br>
<br>
The "Stability of the PNaCl bitcode ABI" [3] document notes that the<br>
translator will be restoring the fastcc convention (though issue #2346<br>
notes this may only happen after the first release). Perhaps we could<br>
support the "tail call" instruction and have the translator ensure an<br>
appropriate calling convention is restored when that is seen? Or<br>
perhaps we could revisit our reluctance to support multiple calling<br>
conventions? Or perhaps we could address the issues with fastcc that<br>
are causing us to reject it, or create a new calling convention that<br>
is simultaneously acceptable for our needs and supports TCO?<br></blockquote><div><br></div><div>This is exactly the kind of feedback we're interested in, and the PNaCl ABI is not set in stone. I'm glad that you went over the "stability" document; it means you noticed that we don't preclude expanding the scope of the bitcode in the future. We do plan to ensure backwards compatibility, but features can be added. If you, or any other interested party, wants to investigate compiling Haskell or some other functional language to PNaCl - please go ahead. Feel free to contact us personally or on the NaCl mailing lists (or even in llvmdev@ for issues that are strictly LLVM IR related) w.r.t. any problems you encounter. If there are additional modes/instructions/attributes that need to be added to the ABI, we'll consider it taking into account all the other constraints.</div>
<div><br></div><div>Eli</div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div></div></div></div>