[LLVMdev] JIT Stub Problem

Ben Mayne bmayne at 21technologies.com
Wed Dec 19 13:07:25 PST 2007

I'm having an issue with the Stubs used by the JIT Compiler.  I'm not sure if it's a bug or if I'm doing something incorrectly.

I've got a long complicated function with the following basic blocks at the end of it (The complete .ll file is attached):

falseBlock:             ; preds = %__exp.exit340
        ret int 617

codeRepl:               ; preds = %__exp.exit340

        %tmp2.i.i = add int %x, 1               ; <int> [#uses=1]

        store int %tmp2.i.i, int* %tmp2.loc

        call void %test3_trueBlock_trueBlock.ret.exitStub_newFuncRoot.ce_trueBlock.ret.exitStub.ret.exitStub.ret.exitStub.ret7( )
        %tmp2.reload = load int* %tmp2.loc              ; <int> [#uses=1]
        %tmp15 = tail call int (sbyte*, ...)* %printf( sbyte* getelementptr ([8 x sbyte]* %str, int 0, uint 0), int %tmp2.reload )         ; <int> [#uses=0]
        br label %trueBlock.ret

trueBlock.ret:          ; preds = %codeRepl
        ret int %tmp2.reload

The variable %tmp2.loc is alloca'd further up in the function but the funny stuff happens here.  In the codeRepl block above, we store tmp2.i.i into
tmp2.loc, call a function, then reload the integer stored in tmp2.loc.  Without the call instruction there, it works just fine.  If we store the value 10 into tmp2.i.i, 10 gets reloaded after the call.  However, the call instruction somehow overwrites the data stored in tmp2.loc which surprises me.  Using the debugger, we watched that memory location and saw that X86CompilationCallback_SSE was modifying it for some reason.  After lookin at 
X86CompilationCallback_SSE, we don't see how it is touching that memory location.

A few other things.  If i move the alloca of tmp2.loc into the codeRepl block, the error does not occur.  If i add a print directly after the current alloca of temp2.loc, the error does not occur.

In addition, here's what the MachineFunction code and the generated machine code look like for these basic blocks.

falseBlock (0xa60cb18, LLVM BB @0xa5ce378, ID#81):
    Predecessors according to CFG: 0xa60ca80
        %EAX = MOV32ri 617
        %EBX = MOV32rm %EBP, 1, %NOREG, -12
        %EDI = MOV32rm %EBP, 1, %NOREG, -8
        %ESI = MOV32rm %EBP, 1, %NOREG, -4
        %ESP = MOV32rr %EBP
        %EBP = POP32r

codeRepl (0xa5f4148, LLVM BB @0xa5ce310, ID#82):
    Predecessors according to CFG: 0xa60ca80
        %EDI = INC32r %EDI
        %EAX = MOV32rm %EBP, 1, %NOREG, -268
        MOV32mr %EAX, 1, %NOREG, 0, %EDI
        CALLpcrel32 <ga:test3_trueBlock_trueBlock.ret.exitStub_newFuncRoot.ce_trueBlock.ret.exitStub.ret.exitStub.ret.exitStub.ret7>
        %EAX = MOV32rm %EBP, 1, %NOREG, -268
        %ESI = MOV32rm %EAX, 1, %NOREG, 0
        %ESP = SUB32ri %ESP, 8
        MOV32mr %ESP, 1, %NOREG, 4, %ESI
        MOV32mi %ESP, 1, %NOREG, 0, <ga:str>
        CALLpcrel32 <ga:printf>
        %ESP = ADD32ri8 %ESP, 8
    Successors according to CFG: 0xa60cb58

trueBlock.ret (0xa60cb58, LLVM BB @0xa5d88c8, ID#83):
    Predecessors according to CFG: 0xa5f4148
        %EAX = MOV32rr %ESI
        %EBX = MOV32rm %EBP, 1, %NOREG, -12
        %EDI = MOV32rm %EBP, 1, %NOREG, -8
        %ESI = MOV32rm %EBP, 1, %NOREG, -4
        %ESP = MOV32rr %EBP
        %EBP = POP32r

0xf5f6f9f8:     mov    $0x269,%eax
0xf5f6f9fd:     mov    0xfffffff4(%ebp),%ebx
0xf5f6fa00:     mov    0xfffffff8(%ebp),%edi
0xf5f6fa03:     mov    0xfffffffc(%ebp),%esi
0xf5f6fa06:     mov    %ebp,%esp
0xf5f6fa08:     pop    %ebp
0xf5f6fa09:     ret

0xf5f6fa0a:     inc    %edi                                     
0xf5f6fa0b:     mov    0xfffffef4(%ebp),%eax                    
0xf5f6fa11:     mov    %edi,(%eax)                              
0xf5f6fa13:     call   0x83e4c28 <X86CompilationCallback_SSE>   
0xf5f6fa18:     mov    0xfffffef4(%ebp),%eax        
0xf5f6fa1e:     mov    (%eax),%esi                              
0xf5f6fa20:     sub    $0x8,%esp
0xf5f6fa26:     mov    %esi,0x4(%esp)
0xf5f6fa2a:     movl   $0x946b908,(%esp)
0xf5f6fa31:     call   0x5ba660 <printf>
0xf5f6fa36:     add    $0x8,%esp

0xf5f6fa39:     mov    %esi,%eax
0xf5f6fa3b:     mov    0xfffffff4(%ebp),%ebx
0xf5f6fa3e:     mov    0xfffffff8(%ebp),%edi
0xf5f6fa41:     mov    0xfffffffc(%ebp),%esi
0xf5f6fa44:     mov    %ebp,%esp
0xf5f6fa46:     pop    %ebp
0xf5f6fa47:     ret

Any help would be appreciated

I have attached the full .ll file.  Upon running it should print out TEST 10TEST 10, but it prints out TEST -XXXXXXXXTEST -XXXXXXXXX where XXXXXXX is some large number.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071219/3ae1f17f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SIMPLE.ll
Type: application/octet-stream
Size: 54320 bytes
Desc: SIMPLE.ll
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071219/3ae1f17f/attachment.obj>

More information about the llvm-dev mailing list