[LLVMdev] JIT on Windows x64
David Bertouille
dbertouille at franticfilms.com
Tue Jun 30 10:09:36 PDT 2009
I also have an example that may be useful. I have the following code
which takes a pointer to a vector. The argument is a i8* since in the
actual implementation that data type is variable but here i simply
assume it is a pointer to 3 floats. There is obviously a lot of
wasteful steps in this code but it is unoptimized and a small part of a
larger project.
The following code runs fine until i add the last step( writing from
stack to the dataPtr). When those lines are added the code crashes on a
movaps instruction.
The extra lines appended (right before the ret void) are:
%27 = load float* %outStackPtr ; <float> [#uses=1]
store float %27, float* %0
%28 = getelementptr float* %outStackPtr, i32 1 ;
<float*> [#uses=2]
%29 = getelementptr float* %0, i32 1 ; <float*> [#uses=2]
%30 = load float* %28 ; <float> [#uses=1]
store float %30, float* %29
%31 = getelementptr float* %28, i32 1 ; <float*> [#uses=1]
%32 = getelementptr float* %29, i32 1 ; <float*> [#uses=1]
%33 = load float* %31 ; <float> [#uses=1]
store float %33, float* %32
Working Code:
; ModuleID = 'module'
target datalayout = "e"
define void @main(i8* %dataPtr) {
mainBB:
%inStackPtr = alloca float, i32 3 ; <float*> [#uses=4]
%0 = bitcast i8* %dataPtr to float* ; <float*> [#uses=2]
%1 = load float* %0 ; <float> [#uses=1]
store float %1, float* %inStackPtr
%2 = getelementptr float* %inStackPtr, i32 1 ;
<float*> [#uses=2]
%3 = getelementptr float* %0, i32 1 ; <float*> [#uses=2]
%4 = load float* %3 ; <float> [#uses=1]
store float %4, float* %2
%5 = getelementptr float* %2, i32 1 ; <float*> [#uses=1]
%6 = getelementptr float* %3, i32 1 ; <float*> [#uses=1]
%7 = load float* %6 ; <float> [#uses=1]
store float %7, float* %5
%8 = load float* %inStackPtr ; <float> [#uses=3]
%9 = getelementptr float* %inStackPtr, i32 1 ;
<float*> [#uses=2]
%10 = load float* %9 ; <float> [#uses=3]
%11 = getelementptr float* %9, i32 1 ; <float*> [#uses=2]
%12 = load float* %11 ; <float> [#uses=3]
%13 = getelementptr float* %11, i32 1 ; <float*> [#uses=0]
%14 = mul float %8, %8 ; <float> [#uses=1]
%15 = mul float %10, %10 ; <float> [#uses=1]
%16 = add float %14, %15 ; <float> [#uses=1]
%17 = mul float %12, %12 ; <float> [#uses=1]
%18 = add float %16, %17 ; <float> [#uses=1]
%19 = fpext float %18 to double ; <double> [#uses=1]
%20 = call double @sqrt(double %19) ; <double> [#uses=1]
%21 = fptrunc double %20 to float ; <float> [#uses=3]
%outStackPtr = alloca float, i32 3 ; <float*> [#uses=2]
%22 = fdiv float %8, %21 ; <float> [#uses=1]
store float %22, float* %outStackPtr
%23 = getelementptr float* %outStackPtr, i32 1 ;
<float*> [#uses=2]
%24 = fdiv float %10, %21 ; <float> [#uses=1]
store float %24, float* %23
%25 = getelementptr float* %23, i32 1 ; <float*> [#uses=1]
%26 = fdiv float %12, %21 ; <float> [#uses=1]
store float %26, float* %25
ret void
}
declare double @sqrt(double)
David Bertouille wrote:
> Hi,
> I'm new to LLVM and have some questions about using the JIT on Windows
> x64. I am aware that this is currently broken but am attempting to use
> the hack/patch proposed in this bug
> http://llvm.org/bugs/show_bug.cgi?id=3739.
>
> I checked out the revision the patch was created for (66183) and applied
> it but the assembler generated seems to fail whenever it reaches a
> movaps insctruction.
> eg.
> movaps xmmword ptr [rsp+20h],xmm8
> movaps xmmword ptr [rsp+30h],xmm7
> movaps xmmword ptr [rsp+40h],xmm6
>
> Would this have something to do with the stack alignment?
>
> I am wondering if anybody else has had any success using that patch to
> get Windows x64 JIT to work correctly. Or if my problem may be unrelated.
>
> Any suggestions would be useful.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> __________ NOD32 4184 (20090624) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
>
>
More information about the llvm-dev
mailing list