[LLVMbugs] [Bug 6774] New: Too much stack manipulation with -tailcallopt on x86

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sun Apr 4 04:50:47 PDT 2010


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

           Summary: Too much stack manipulation with -tailcallopt on x86
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: batterseapower at hotmail.com
                CC: llvmbugs at cs.uiuc.edu


The GHC LLVM backend generates code with lots of tail calls, and we use
-tailcallopt to ensure that these are turned into actual "jmp" instructions.

Unfortunately, the -tailcallopt option seems to lead to excessive manipulation
of the stack pointer. Here is some an example IR fragment generated from some
relatively simple Haskell code:

{{{
define cc10 void @Toy_toy_entry(i32 %stg_terei_baseArg, i32
%stg_terei_spArg, i32 %stg_terei_hpArg, i32 %stg_terei_r1Arg) nounwind
{
cdx:
  %ndz = add i32 %stg_terei_spArg, -4             ; <i32> [#uses=3]
  %ndB = add i32 %stg_terei_baseArg, 84           ; <i32> [#uses=1]
  %ndC = inttoptr i32 %ndB to i32*                ; <i32*> [#uses=1]
  %ndD = load i32* %ndC                           ; <i32> [#uses=1]
  %ndE = icmp ult i32 %ndz, %ndD                  ; <i1> [#uses=1]
  br i1 %ndE, label %cdG, label %ndH

ndH:                                              ; preds = %cdx
  %ndJ = inttoptr i32 %stg_terei_spArg to i32*    ; <i32*> [#uses=2]
  %ndK = load i32* %ndJ                           ; <i32> [#uses=1]
  %ndP = inttoptr i32 %ndz to i32*                ; <i32*> [#uses=1]
  store i32 add (i32 ptrtoint (%Toy_toy1_closure_struct*
@Toy_toy2_closure to i32), i32 1), i32* %ndP
  store i32 ptrtoint (%sbo_info_struct* @sbo_info to i32), i32* %ndJ
  tail call cc10 void @stg_ap_p_fast(i32 %stg_terei_baseArg, i32 %ndz,
i32 %stg_terei_hpArg, i32 %ndK) nounwind
  ret void

cdG:                                              ; preds = %cdx
  %ne1 = add i32 %stg_terei_baseArg, -4           ; <i32> [#uses=1]
  %ne2 = inttoptr i32 %ne1 to i32*                ; <i32*> [#uses=1]
  %ne3 = load i32* %ne2                           ; <i32> [#uses=1]
  %ne4 = inttoptr i32 %ne3 to void (i32, i32, i32, i32)* ; <void (i32,
i32, i32, i32)*> [#uses=1]
  tail call cc10 void %ne4(i32 %stg_terei_baseArg, i32
%stg_terei_spArg, i32 %stg_terei_hpArg, i32 ptrtoint
(%Toy_toy_closure_struct* @Toy_toy_closure to i32)) nounwind
  ret void
}
}}}

With -tailcallopt, llc generates the following x86:

{{{
_Toy_toy_entry:                         ## @Toy_toy_entry
## BB#0:                                ## %cdx
    subl    $12, %esp
    leal    -4(%ebp), %eax
    cmpl    84(%ebx), %eax
    jb    LBB2_2
## BB#1:                                ## %ndH
    movl    (%ebp), %esi
    movl    $_Toy_toy2_closure+1, -4(%ebp)
    movl    $_sbo_info, (%ebp)
    movl    %eax, %ebp
    addl    $12, %esp
    jmp    _stg_ap_p_fast  # TAILCALL
LBB2_2:                                 ## %cdG
    movl    -4(%ebx), %eax
    movl    $_Toy_toy_closure, %esi
    addl    $12, %esp
    jmpl    *%eax  # TAILCALL

    .globl    ___stginit_Toy_
    .align    4, 0x90
}}}

Note the subl of %esp at the end point and corresponding addl to %esp at both
exit points. %esp is not used in the body of the function, so this is
pointless.

Compiling without -tailcallopt removes this extra stack manipulation.

As far as I can see, the two tail calls meet the requirements for "sibling
calls" - and indeed llc without -tailcallopt still turns the calls into "jmp"s.
Is it possible for LLVM to try this approach first, and only fall back on the
full tail-call optimisation if it can't apply the simpler sibling-call
optimisation?

(See also my post to the GHC mailing list at
http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/38323)

-- 
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