[LLVMdev] Tail calls (TCO) in PNaCL | PNaCl Bitcode reference manual

[Mark Seaborn]

On 1 August 2013 00:11, Travis Cross <tc at travislists.com> wrote:

> On 2013-07-30 22:11, Eli Bendersky wrote:
> > we've published an initial version of the PNaCl bitcode reference
> > manual online -
> > http://www.chromium.org/nativeclient/pnacl/bitcode-abi. The PNaCl
> > bitcode is a restricted subset of LLVM IR.
> >
> > Any comments would be most welcome.
>
> Hi Eli,
>
> I appreciate you for opening the process for input and comments.  One
> question stood out to me while reading the document:
>
> The document [1] indicates that only the 'ccc' calling convention will
> be supported.  The LLVM documentation [2] prominently notes that,
> "tail calls can only be optimized when [fastcc], the GHC or the HiPE
> convention is used."


That note in the documentation seems to be incorrect, because LLVM will do
tail call optimisations on at least x86 when using the "ccc" calling
convention.  For example:

$ cat tail_call1.c
void foo(int arg);
void bar(int arg) {
  foo(arg);
}

$ clang tail_call1.c -S -o - -O2
...
bar:                                    # @bar
...
    jmp    foo                     # TAILCALL
...

However, LLVM doesn't emit a tail call at -O0.

Maybe what the documentation means to say is that tail call optimisations
are only guaranteed to be done when using fastcc etc.?


Further, I notice that the document includes
> "call" but not "tail call" in the list of supported instructions.
>

That's an omission in the document.  We do actually allow the "tail call"
instruction in PNaCl.

However, we haven't specified any guarantees that a tail call optimisation
will happen.  I suppose we could specify some guarantees if people want
this.  Maybe we could say that a "tail call" instruction is guaranteed to
be turned into a real tail call if the callee function has the same number
of arguments as the caller function or fewer?  I think that would work on
all the architectures PNaCl targets.

Then we would have to change -O0 translation so that the guarantee is
provided consistently at all optimisation levels.

Cheers,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130801/1719e45f/attachment.html>