search for: compilationcallback

...ompiled and patched patchsite: jmp <nop nop nop nop nop nop nop nop> // will be patched } // not yet patched, it may already be compiling if (atomic_test_and_set(&callsite_patch_state, 0, 1) == 0) { // not yet compiling, set state to compiling, and start compiling call CompilationCallBack // set state to patched atomic_set(&callsite_patch_state, 2) } // wait for patched state while (atomic_load(&callsite_patch_state) != 2) { waitJIT(); } // serialize CPUID patchsite2: // execute new code jmp <nop nop nop nop nop nop nop nop> // will be patched waitJIT:...

...he bug so we don't lose it? I think we can put the entire "not yet patched" branch inside the compilation callback to minimize the code size impact: callsite_patch_state = 0;// for each callsite one byte of memory callsite: if (atomic_load(&callsite_patch_state) != 2) { call CompilationCallback // Doesn't return until the patchsite is patched. } //fast- and slow-path: already compiled and patched patchsite: call <nop nop nop nop nop nop nop nop> // will be patched > callsite_patch_state = 0;// for each callsite one byte of memory > > callsite: > if  (atomic_l...

...I tried to build LLVM. The tar file is llvm-1.3.tar.gz. I am using a sparc machine with gcc 3.2.2. ------------- Compiling SparcV9CodeEmitter.cpp /uf24/zhou/research/llvm/src/lib/Target/SparcV9/SparcV9CodeEmitter.cpp: In static member function `static void llvm::<unnamed>::JITResolver::CompilationCallback()': /uf24/zhou/research/llvm/src/lib/Target/SparcV9/SparcV9CodeEmitter.cpp:340: warning: cast to pointer from integer of different size /usr/ccs/bin/as: "/var/tmp//ccFz2VBS.s", line 3147: error: cannot use v8plus registers in a non-v8plus target binary ... ------------- There are 42...

If you look in X86JITInfo.cpp, you'll find CompilationCallback. I'm not sure about CompilationCallback2. In any event, the code is conditionally compiled and that might be tripping things up on Cygwin. Reid. On Mon, 2005-05-30 at 17:17 +0100, Aaron Gray wrote: > Consistant error building LLVM on Cygwin from CVS :- > > make[2]: Entering direct...

...g14LowerArgumentsERN4llvm8FunctionERNS1_12SelectionDAGE': /usr/src/llvm/lib/Target/X86/X86ISelPattern.cpp:73: undefined reference to `X86C ompilationCallback2' /usr/build/llvm/Debug/lib/LLVMX86.o(.text+0x305f2):/usr/src/llvm/lib/Target/X86/ X86ISelPattern.cpp:73: undefined reference to `_X86CompilationCallback' /usr/build/llvm/Debug/lib/LLVMX86.o(.text+0x30601):/usr/src/llvm/lib/Target/X86/ X86ISelPattern.cpp:73: undefined reference to `_X86CompilationCallback' collect2: ld returned 1 exit status make[2]: *** [/usr/build/llvm/Debug/bin/llc.exe] Error 1 make[2]: Leaving directory `/usr/build/llvm/...

...I think we can put the entire "not yet patched" branch inside the > compilation callback to minimize the code size impact: > > callsite_patch_state = 0;// for each callsite one byte of memory > > callsite: > if (atomic_load(&callsite_patch_state) != 2) { > call CompilationCallback // Doesn't return until the patchsite is patched. > } > //fast- and slow-path: already compiled and patched > patchsite: > call <nop nop nop nop nop nop nop nop> // will be patched > > Yes, that sounds good (except that we'd want a jmp instead of a call I...

...is > llvm-1.3.tar.gz. I am using a sparc machine with gcc 3.2.2. > > ------------- > Compiling SparcV9CodeEmitter.cpp > /uf24/zhou/research/llvm/src/lib/Target/SparcV9/SparcV9CodeEmitter.cpp: In > static member function `static void > llvm::<unnamed>::JITResolver::CompilationCallback()': > /uf24/zhou/research/llvm/src/lib/Target/SparcV9/SparcV9CodeEmitter.cpp:340: > warning: cast to pointer from integer of different size > /usr/ccs/bin/as: "/var/tmp//ccFz2VBS.s", line 3147: error: cannot use > v8plus registers in a non-v8plus target binary > ... &gt...

...breakage on FreeBSD/powerpc: Index: lib/Target/PowerPC/PPCJITInfo.cpp =================================================================== --- lib/Target/PowerPC/PPCJITInfo.cpp (revision 51432) +++ lib/Target/PowerPC/PPCJITInfo.cpp (working copy) @@ -72,7 +72,7 @@ extern "C" void PPC64CompilationCallback(); #if (defined(__POWERPC__) || defined (__ppc__) || defined(_POWER)) && \ - !defined(__ppc64__) + !(defined(__ppc64__) || defined(__FreeBSD__)) // CompilationCallback stub - We can't use a C function with inline assembly in // it, because we the prolog/epilog inserted...

On Thu, Oct 29, 2009 at 2:30 PM, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > Hi Jeffrey, > > Jeffrey Yasskin wrote: >> >> Cool, I'll start implementing it. >> > > Great! Thanks. > > Just to clarify things: on my end, it doesn't really matter what is the > default behavior, as long as vmkit can continue to have the existing >

Paolo Invernizzi wrote: > There was a similar problem some time ago, and was resolved with alloca. > I think it's a better solution to use the stack instead of the heap... I tend to agree, but the constructors won't get called if it's an object array -- anyway, this particular case there was no objects, just pointers and bools so alloca should be fine. I'll leave it to

Hi Jeffrey, Jeffrey Yasskin wrote: > Cool, I'll start implementing it. > Great! Thanks. Just to clarify things: on my end, it doesn't really matter what is the default behavior, as long as vmkit can continue to have the existing behavior of lazy compilation. With Chris' solution, I was wondering how you would implement the getPointerToFunction{Eager, Lazy} functions when