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>