Bruce Hoult
2015-Jan-13 11:59 UTC
[LLVMdev] [RFC] [PATCH] add tail call optimization to thumb1-only targets
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>