[LLVMdev] [RFC] [PATCH] add tail call optimization to thumb1-only targets

[Bruce Hoult]

That link says "currently supported on x86/x86-64 and PowerPC". The purpose
of the current patch appears to be adding support for this flag for Thumb-1?

(with the implication that it is already supported for Thumb-2 and ARM32
and the documentation is out of date)

I could, of course, be confused.

On Tue, Jan 13, 2015 at 11:55 PM, John Brawn <john.brawn at arm.com> wrote:

> Forcing tailcalls, even when it isn’t profitable in terms of performance
> (or space in the case of
>
> -Os, though I can’t off the top of my head think of any case where a
> faster tail call would also
>
> be larger), is what the -tailcallopt option is for: see
>
> http://llvm.org/docs/CodeGenerator.html#tail-call-optimization
>
>
>
> John
>
>
>
>
>
> *From:* bruce.hoult at gmail.com [mailto:bruce.hoult at gmail.com] *On Behalf
> Of *Bruce Hoult
> *Sent:* 13 January 2015 00:01
> *To:* John Brawn
> *Subject:* Re: [LLVMdev] [RFC] [PATCH] add tail call optimization to
> thumb1-only targets
>
>
>
> On Tue, Jan 13, 2015 at 3:50 AM, John Brawn <john.brawn at arm.com> wrote:
>
> > During epilog generation, spill register restoring will be done within
> > the emit epilogue function.
> > If LR happens to be spilled on the stack by the prologue, it's restored
> > by use of a scratch register
> > just before restoring the other registers.
>
> POP is 1+N cycles whereas LDR is 2 cycles. If we need to LDR lr from the
> stack then POP r4 then that's 2 (LDR) + 1+1 (POP) + 1 (MOV to lr) + 1
> (ADD sp) = 6 cycles, but a POP {r4,lr} is just 3 cycles.
>
>
>
> You appear to be using speed as the figure of merit, but that is not the
> point of tail call optimisation (except incidentally).
>
>
>
> TCO is to minimise the use of precious stack space, and in fact to allow
> certain algorithms and program transformations to run in constant stack
> space.
>
>
>
> If a programmer assumes that TCO is available and writes their program
> using continuation-passing style, and then TCO does not actually happen,
> that is a correctness issue and the program will overflow the stack and
> crash very quickly.
>
>
>
> A few register loads or spills is a distant second consideration.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/c3b4f164/attachment.html>