[LLVMbugs] [Bug 4279] New: Tail calls not used when possible without -tailcallopt

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Thu May 28 03:12:04 PDT 2009


http://llvm.org/bugs/show_bug.cgi?id=4279

           Summary: Tail calls not used when possible without -tailcallopt
           Product: new-bugs
           Version: unspecified
          Platform: PC
               URL: http://llvm.org/docs/CodeGenerator.html#tailcallopt
        OS/Version: Linux
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fvbommel at wxs.nl
                CC: llvmbugs at cs.uiuc.edu


Not all cases where tail calls are possible should require -tailcallopt.
For caller-pops calling conventions (like non-"-tailcallopt" x86-64 fastcc), it
should be possible to generate tailcalls if the arguments to the callee take up
no more stack space than the arguments to the caller.
On targets like x86-64 many functions pass parameters entirely in registers, so
any time one such function calls another in tail call position the optimization
might be applied.


Another related thing I was wondering about: why is CC_X86_64_TailCall using R9
for the function pointer case instead of R11? R11 isn't normally a parameter
register (as opposed to R9) and is caller-saved.
In fact, according to the System V ABI document for x86-64, R11 is available as
scratch register for PLT code, so it can't be used for much else anyway. (This
may only apply to Linux, I'm not sure whether this ABI is used on other
operating systems[1])

As far as I can tell, once bug 4278 is fixed[2] the only difference actually
needed between the regular calling convention and the one for -tailcallopt is
caller-pops/callee-pops.

(At that point, the fastcc requirement also seems rather arbitrary, especially
since ccc uses the exact same calling convention on x86-64 if -tailcallopt
isn't used)


[1]: Not that this should be a problem for fastcc anyway unless R11 is used for
something else I'm unaware of on any of the other operating systems that would
require it to be preserved.
[2]: Minus the comment mismatch if R11 is substituted for R9 and the latter is
re-instated as last integer parameter register, of course.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list