thr3ads.net - llvm dev - [LLVMdev] Code Generation Problem llvm 1.9 [Dec 2007]

If this information is useful, please help other people find it:
Share via:

Ben Mayne

2007-Dec-20 20:54 UTC

[LLVMdev] Code Generation Problem llvm 1.9

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20071220/a2102e29/attachment.html>

Evan Cheng

2007-Dec-20 23:06 UTC

head link

[LLVMdev] Code Generation Problem llvm 1.9

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>

Maybe Matching Threads

Search for more maybe matching threads

llvm dev - Dec 2007 - [LLVMdev] Code Generation Problem llvm 1.9

[LLVMdev] Code Generation Problem llvm 1.9

[LLVMdev] Code Generation Problem llvm 1.9

Maybe Matching Threads