[LLVMdev] Code Generation Problem llvm 1.9
Evan Cheng
evan.cheng at apple.com
Thu Dec 20 15:06:11 PST 2007
llvm 1.9 is fairly old. Please move to top of tree and try to
reproduce the problem if possible.
Then please file a bugzilla report with reproducible test case and
information about system configuration.
Thanks,
Evan
On Dec 20, 2007, at 12:54 PM, Ben Mayne wrote:
> I sent a long message yesterday describing a problem I thought had
> to do with the JIT stubs.
> After further investigating, the problem seems to be in the code
> generation.
>
> The following basic block seems to have an error in it's code
> generation:
>
> __exp.exit: ; preds = %codeRepl258, %__exp_bb_bb.exit
> phi double [ 1.000000e+00, %codeRepl258 ],
> [ %.reload.reload.i, %__exp_bb_bb.exit ] ; <double>:30
> [#uses=2]
> %castPointerToLong10 = cast [10 x double]* %DataStore to
> long ; <long> [#uses=1]
> %pointerArithmetic11 = add long %castPointerToLong10,
> 0 ; <long> [#uses=1]
> %castPointerToLong9 = cast [10 x double]* %DataStore to
> long ; <long> [#uses=1]
> %pointerArithmetic10 = add long %castPointerToLong9,
> 40 ; <long> [#uses=1]
> %castLongToGV11 = cast long %pointerArithmetic10 to
> double* ; <double*> [#uses=1]
> store double 7.000000e+00, double* %castLongToGV11
> %castPointerToLong12 = cast [10 x double]* %DataStore to
> long ; <long> [#uses=1]
> %pointerArithmetic13 = add long %castPointerToLong12,
> 16 ; <long> [#uses=1]
> %tmp2.loc = alloca int ; <int*> [#uses=2]
> %castLongToGV14 = cast long %pointerArithmetic13 to
> double* ; <double*> [#uses=1]
> store double 2.000000e+00, double* %castLongToGV14
> cast int %x to double ; <double>:31 [#uses=1]
> frem double %31, 1.000000e+02 ; <double>:32
> [#uses=2]
> %castPointerToLong15 = cast [10 x double]* %DataStore to
> long ; <long> [#uses=1]
> %pointerArithmetic16 = add long %castPointerToLong15,
> 24 ; <long> [#uses=1]
> %castLongToGV17 = cast long %pointerArithmetic16 to
> double* ; <double*> [#uses=1]
> store double %32, double* %castLongToGV17
> %castPointerToLong18 = cast [10 x double]* %DataStore to
> long ; <long> [#uses=1]
> %pointerArithmetic19 = add long %castPointerToLong18,
> 24 ; <long> [#uses=1]
> %castLongToGV20 = cast long %pointerArithmetic19 to
> double* ; <double*> [#uses=1]
> load double* %castLongToGV20 ; <double>:33
> [#uses=1]
> %castPointerToLong21 = cast [10 x double]* %DataStore to
> long ; <long> [#uses=1]
> %pointerArithmetic22 = add long %castPointerToLong21,
> 16 ; <long> [#uses=1]
> %castLongToGV23 = cast long %pointerArithmetic22 to
> double* ; <double*> [#uses=1]
> load double* %castLongToGV23 ; <double>:34
> [#uses=1]
> cast double %34 to int ; <int>:9 [#uses=2]
> seteq int %9, 0 ; <bool>:7 [#uses=1]
> br bool %7, label %entry.bb19_crit_edge.i270, label
> %bb.preheader.i271
>
> It gets converted to the following MachineBasicBlock
> __exp.exit (0x8c58628, LLVM BB @0x8c1c558, ID#21):
> Predecessors according to CFG: 0x8c53a90 0x8c55b50
> MOV32mi %EBP, 1, %NOREG, -224, <ga:DataStore>
> %EAX = MOV32rm %EBP, 1, %NOREG, -224
> %EAX = ADD32ri8 %EAX, 40
> MOV32mi %EAX, 1, %NOREG, 0, 0
> MOV32mi %EAX, 1, %NOREG, 4, 1075576832
> %ESP = SUB32ri %ESP, 16
> %XMM0 = CVTSI2SDrr %EDI
> MOVSDmr %ESP, 1, %NOREG, 0, %XMM0
> MOV32mr %EBP, 1, %NOREG, -268, %ESP
> ADD32mi8 %EBP, 1, %NOREG, -268, 4294967288
> %ESP = MOV32rm %EBP, 1, %NOREG, -268
> %ESI = MOV32rm %EBP, 1, %NOREG, -224
> %ESI = ADD32ri8 %ESI, 16
> MOV32mi %ESI, 1, %NOREG, 0, 0
> MOV32mi %ESI, 1, %NOREG, 4, 1073741824
> MOV32mi %ESP, 1, %NOREG, 12, 1079574528
> MOV32mi %ESP, 1, %NOREG, 8, 0
> CALLpcrel32 <es:fmod>
> %ESP = ADD32ri8 %ESP, 16
> FSTP64m %EBP, 1, %NOREG, -160
> %EAX = MOV32rm %EBP, 1, %NOREG, -224
> %EAX = ADD32ri8 %EAX, 24
> %XMM0 = MOVSDrm %EBP, 1, %NOREG, -160
> MOVSDmr %EBP, 1, %NOREG, -232, %XMM0
> MOVSDmr %EAX, 1, %NOREG, 0, %XMM0
> %EAX = CVTTSD2SIrm %ESI, 1, %NOREG, 0
> %ECX = MOV32r0
> TEST32rr %EAX, %EAX
> JNE mbb<bb.preheader.i271,0x8c55330>
> Successors according to CFG: 0x8c55330 0x8c573b0
>
> The gdb disassembler gives me the following lines for that basic block
>
> __exp.exit:
> 0xf5f6f317: movl $0xa542b70,0xffffff20(%ebp)
> 0xf5f6f321: mov 0xffffff20(%ebp),%eax
> 0xf5f6f327: add $0x28,%eax
> 0xf5f6f32a: movl $0x0,(%eax)
> 0xf5f6f330: movl $0x401c0000,0x4(%eax)
> 0xf5f6f337: sub $0x10,%esp
> 0xf5f6f33d: cvtsi2sd %edi,%xmm0
> 0xf5f6f341: movsd %xmm0,(%esp)
> 0xf5f6f346: mov %esp,0xfffffef4(%ebp)
> 0xf5f6f34c: addl $0xfffffff8,0xfffffef4(%ebp)
> 0xf5f6f353: mov 0xfffffef4(%ebp),%esp
> 0xf5f6f359: mov 0xffffff20(%ebp),%esi
> 0xf5f6f35f: add $0x10,%esi
> 0xf5f6f362: movl $0x0,(%esi)
> 0xf5f6f368: movl $0x40000000,0x4(%esi)
> 0xf5f6f36f: movl $0x40590000,0xc(%esp)
> 0xf5f6f377: movl $0x0,0x8(%esp)
> 0xf5f6f37f: call 0xf5f6effb
> 0xf5f6f384: add $0x10,%esp
> 0xf5f6f387: fstpl 0xffffff60(%ebp)
> 0xf5f6f38d: mov 0xffffff20(%ebp),%eax
> 0xf5f6f393: add $0x18,%eax
> 0xf5f6f396: movsd 0xffffff60(%ebp),%xmm0
> 0xf5f6f39e: movsd %xmm0,0xffffff18(%ebp)
> 0xf5f6f3a6: movsd %xmm0,(%eax)
> 0xf5f6f3aa: cvttsd2si (%esi),%eax
> 0xf5f6f3ae: xor %ecx,%ecx
> 0xf5f6f3b0: test %eax,%eax
> 0xf5f6f3b2: jne 0xf5f6f3c5
>
>
> The problem I'm seeing is that the generated code for the "%tmp2.loc
> = alloca int" instruction seems to get placed in the middle of
> the generated code for the "frem double %31, 1.000000e+02"
> instruction. The generated code for the frem call subtracts 16 from
> the stack to
> prepare for the insertion of arguments onto the stack. However,
> before it insert the arguments on the stack, it allocates space for
> tmp2.loc.
> Therefore the stack essentially gets subtracted by 10 more. Then
> the arguments are placed on, the call is made, and upon return, 16
> is added to
> the stack. Basically, after the call, the stack doesn't go back to
> the state it was in before the call because the alloca snuck in
> between
> the instructions. Now, tmp2.loc is sitting in memory past the stack
> pointer which can potentially be overwritten by a future call and in
> the example
> I sent yesterday, it does get overwritten.
>
> Thanks,
>
> Ben Mayne
> x245
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071220/2e7ce979/attachment.html>
More information about the llvm-dev
mailing list