[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
RET
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
RET
falseBlock:
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
codeRepl:
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
trueBlock.ret:
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.
Thanks,
Ben
-------------- 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