similar to: [LLVMdev] Enabling x86-64 JIT under Visual Studio compiler

I built the LLVM 2.2 distribution under Visual Studio for x86-64 just fine, but then trying to run my first "hello world" application, found that the JIT compiler was not enabled. I'm completely new to LLVM, so I didn't know exactly where to look to see why the JIT for my platform wasn't being built (is it in the configure steps, or in the C++ code itself?). My educated guess

On 02/03/2010 01:08 PM, Kristaps Straupe wrote: > Hello again. > > I still think that you are wrong. Realignement with and esp,-16 not > always changes stack poiner. If esp is already aligned to 16 byte > boundary, it will not change! Take a look at following example. > Assume esp has value 0x000001000 at start of X86CompilationCallback > function. Then execution of it will

2012/5/24 Mikael Lyngvig <mikael at lyngvig.org>: > I know that the documentation says that I am to install GnuWin32 tools, but > I strongly oppose that idea.  We Windows people have our own tools and > practices and I think the LLVM developers should open up to a more > multi-platform approach than the current (Unix then, perhaps maybe, Windows) > approach.  CMake works

FYI, I have confirmed it works on VS10SP1 with x64|Release. E:\llvm\build\cmake-x64-vs10>bin\Release\Fibonacci.exe 24 verifying... OK We just constructed this LLVM module: --------- ; ModuleID = 'test' (snip) --------- starting fibonacci(24) with JIT... Result: 46368 ...Takumi 2011/8/11 <gleizesd at gmail.com>: > Hello everybody, > > I have sucessfully compiled LLVM

Hello everybody, I have sucessfully compiled LLVM with CMAKE generator "Visual Studio 9 2008 Win64" (OS Windows 7). -But when I run the Fibonacci example program in "release" mode, I get a crash with this visual studio popup message : Microsoft Visual Studio C Runtime Library has detected a fatal error in Fibonacci.exe. -Here is the visual studio output:

Ruben Van Boxem <vanboxem.ruben at gmail.com> writes: >>> I'm trying to build svn LLVM with Visual Studio 2010: >>> >>> cd build >>> cmake .. -G"NMake Makefiles" >>> nmake >>> >>> and several link steps fail due to a missing symbol: >>> >>> > LLVMX86CodeGen.lib(X86JITInfo.cpp.obj) : error

2010/12/31 Francois Pichet <pichet2000 at gmail.com>: > I don't normally build using nmake.. but I just tried and it worked 100% > here. > Are you sure you are using the trunk? > > On Fri, Dec 31, 2010 at 7:32 AM, Ruben Van Boxem <vanboxem.ruben at gmail.com> > wrote: >> >> I first sent this to the Clang dev list, but they told me to come here:

Hello, I am trying to use LLVM JIT to emit the following codes and execute both functions in my program, but I get segmentation fault, the problem seems to originate from "thread_local" global variable. my LLVM library is 3.1 and platform is x86 32bit , OS : Ubuntu 10.04 @0 = internal thread_local global i32 522, align 4 define void @setValue(i32 %v) { %1 = alloca i32,

Hi again, The Visual Studio getting started guide ( http://llvm.org/docs/GettingStartedVS.html) mentions the "llvm-lit" tool, but fails to mention these things: 1. Either you need to run it from bash or a similar Unix shell, as Windows does not recognize the extensionless Python script that it is. 2. Alternatively, you can invoke it using Python like this: python bin/llvm-lit

Hi, > I am trying to use LLVM JIT to emit the following codes and execute > both functions in my program, but > > I get segmentation fault, the problem seems to originate from "thread_local" > global variable. > > my LLVM library is 3.1 and platform is x86 32bit , OS : Ubuntu 10.04 try passing -use-mcjit to lli. The old JIT implementation didn't

Hello, Everyone. Now I have some spare time and I've decided to build LLVM on Mingw. I've grab the latest 1.7 release (not CVS snapshot). Here are some issues fixed during the build. Now I'm preparing gcc build. So, I think, there will some other "parts" 1. Prerequisites 1.1 GCC 3.4.5 from mingw.org site. $ gcc --version gcc.exe (GCC) 3.4.5 (mingw special) Copyright (C)

Hello again. I still think that you are wrong. Realignement with and esp,-16 not always changes stack poiner. If esp is already aligned to 16 byte boundary, it will not change! Take a look at following example. Assume esp has value 0x000001000 at start of X86CompilationCallback function. Then execution of it will yield following esp values: 0x000000FFC - after push ebp 0x000000FFC - after mov

Hello! We are running bitcode with JIT on visual studio project and we get strange external function call problems (jit generates jump to 00000000 address as can be seen in debugger) for libgcc functions like __fixunsdfdi, __divdi3 etc. Currently we have attached our own implementations of these functions to overcome this problem. What would be the correct way to do this on Visual Studio? Why

Hello > The bitcode was generated by llvm-gcc v2.6 for Mingw32/x86, which is > available for download at the llvm site. > Please let me know, if i should tell more. Well, the answer is pretty obvious then. These calls are not generated by JIT. They are already in your bitcode - they are generated by llvm-gcc. The purpose of these calls were alreade explained by Eli. You should either

Microsoft Visual Studio 2012, or 2012 with Update 1, intermittently (90% of the time in my case) crashes when the "Disassembly Window" is opened at the address of JIT code generated by LLVM. This happens when either entering the address into the address bar of the Disassembly Window, or stepping into JIT code that opens the Disassembly Window. Microsoft has acknowledged the crash to

Hello, Willow > Hello, I want to use LLVM to develop a 64-bit operating system (64-bit > Win64 DLL targets) on a 32-bit Windows host. Is this possible? In general - yes, however inw64 codegeneration is work-in-progress and there are some issues with it. > `/c/Downloads/llvm-2.3/llvm-2.3/Release/bin/ > tblgen.exe', needed by How you're configuring? > of running the DLLs

Hi! We are running llvm jit x86 on MS Visual Studio 2005. It seems there is a bug in asm code in function X86CompilationCallback in file X86JITInfo.cpp. Current code sets stack pointer to invalid value in instruction "and esp, 16". Depending on current stack pointer value it sometimes overwrites ecx and edx registers with next three lines. We have fixed this problem by changing this

I see that JIT isn't supported for the Sparc targets for example. What is the scope of the change to add JIT support. I see, for example, that for X86 target class X86JITInfo is defined with 10 methods. It's only used in one place: setPICBase. Also createX86JITCodeEmitterPass creates JIT pass -- very simple. So is implementing these steps enough to add JIT, or there are some hidden

Hello, Chuck > Would my life be made fantastically simpler if I were using a different > calling convention for my callback functions on x64 running on Windows? Yes, surely. You can still use 'normal' x86-64 CC if you don't want to call any external functions from code being JITed. Also note a Win64 fixme in the X86CompilationCallback2 function, this can be your case. I think

Hello > We are running llvm jit x86 on MS Visual Studio 2005. It seems there > is a bug in asm code in function X86CompilationCallback in file > X86JITInfo.cpp. Current code sets stack pointer to invalid value in > instruction "and   esp,  16". Depending on current stack pointer value > it sometimes overwrites ecx and edx registers with next three lines. How so? The stack