search for: emitfunctionstub

...which loop1 needs. According to the x86-64 ABI, r10 > isn't preserved across functions, but here it needs to be. Is there anyway > to force LLVM to do that? you must be the first person to try using nest functions with the JIT :) If you look in X86JITInfo.cpp, in the function X86JITInfo::emitFunctionStub, you will see the code generating the stub and using r10. I think the right solution is to change r10 to a different call clobbered register. It would also be possible to have the trampoline use a different register, but since the x86-64 ABI explicitly states that r10 should be used for the stati...

...B of the text segment. > This causes problems for the usage of LLVM in JITs > since the JIT can no longer patch the callsite after the callee have been > compiled. As far as I know, the JIT only tries to patch the callsite when it's compiling lazily. In that case, it uses X86JITInfo::emitFunctionStub() to emit a stub with known layout that it can patch. It doesn't try to patch the call to the stub. If you've found a broken case here, could you send a (small!) test program with its compilation line, or a patch to http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ExecutionEngine/J...

Fellow developers, I'm parallelizing loops to be called by pthread. The thread body that I pass to pthread_create looks like define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) parent_frame is pointer to shared variables in original function 0x00007f0de11c41f0: mov (%r10),%rax 0x00007f0de11c41f3: cmpl $0x63,(%rax) 0x00007f0de11c41f6: jg 0x7f0de11c420c

Hi, After this commit: http://llvm.org/viewvc/llvm-project?view=rev&revision=88984 the X86 JIT no longer emits calls using call <ADDR>, but always uses mov REG, <ADDR>, call *REG. This causes problems for the usage of LLVM in JITs since the JIT can no longer patch the callsite after the callee have been compiled. According to the comments for the commit, this was done to fix the

.../build/Debug/lib/LLVMX86.o: In function `llvm::X86JITInfo::getLazyResolverFunction(void* (*)(void*))': /home/rafael/dev/llvm/cvs/lib/Target/X86/X86JITInfo.cpp:219: undefined reference to `X86CompilationCallback' /home/rafael/dev/llvm/build/Debug/lib/LLVMX86.o: In function `llvm::X86JITInfo::emitFunctionStub(void*, llvm::MachineCodeEmitter&)': /home/rafael/dev/llvm/cvs/lib/Target/X86/X86JITInfo.cpp:225: undefined reference to `X86CompilationCallback' 68: 0000000000000000 0 NOTYPE GLOBAL DEFAULT 21 _X86CompilationCallback 69: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UN...

On 11 Jun 2007, at 22:35, Jan Rehders wrote: > It's inside PPCJITInfo::relocate but unfortunately I could not figure > out anything from the source. It looks like it's calculating new > addresses for functions which does not make much sense for a native > function, at all On the PPC, unconditional branches are limited to 24 bit signed displacements. When you call a function

Hi, > I know nothing about this, but the failed assertion suggests the PPC > code generator can't cope with a constant that's bigger than > expected at > that point. Have you taken a look at PPCJITInfo.cpp:382? It may shed > some light. It's inside PPCJITInfo::relocate but unfortunately I could not figure out anything from the source. It looks like it's

...> This causes problems for the usage of LLVM in JITs > > since the JIT can no longer patch the callsite after the callee have been > > compiled. > > As far as I know, the JIT only tries to patch the callsite when it's > compiling lazily. In that case, it uses X86JITInfo::emitFunctionStub() > to emit a stub with known layout that it can patch. It doesn't try to > patch the call to the stub. > > If you've found a broken case here, could you send a (small!) test > program with its compilation line, or a patch to > > http://llvm.org/viewvc/llvm-project/llvm...

...esumably needs to generate such stubs for native functions > introduced at run time as well, which it may not yet do. I have not > looked into the code though, so I can't really say for sure what goes > wrong here. The LLVM PPC JIT certainly does produce these stubs. The PPCJITInfo::emitFunctionStub method is the one that actually creates them :) Jan, how are you doing this? Are you creating an external LLVM Function object named "get5", then using EE::addGlobalMapping? If 'get5' exists in the address space, why not just let the JIT resolve it (which will then create t...

On Mon, 16 Jun 2008, Gary Benson wrote: > When you genetate code on PowerPC you need to explicitly invalidate > the instruction cache to force the processor to reread it. In LLVM > there is code to do this for function stubs on Macintosh, but not > for other platforms and not for JITted code generally. Applied, thanks!

...)) && \ +defined(__APPLE__) sys_icache_invalidate(Addr, len); #elif defined(__GNUC__) const size_t LineSize = 32; @@ -352,8 +349,6 @@ asm volatile("icbi 0, %0" : : "r"(Line)); asm volatile("isync"); #endif - -#endif } void *PPCJITInfo::emitFunctionStub(const Function* F, void *Fn, @@ -372,7 +367,7 @@ MCE.emitWordBE(0); MCE.emitWordBE(0); EmitBranchToAt(Addr, (intptr_t)Fn, false, is64Bit); - SyncICache((void*)Addr, 7*4); + InvalidateInstructionCache((void*)Addr, 7*4); return MCE.finishFunctionStub(F); } @@ -400,7 +39...

Hi all, When you genetate code on PowerPC you need to explicitly invalidate the instruction cache to force the processor to reread it. In LLVM there is code to do this for function stubs on Macintosh, but not for other platforms and not for JITted code generally. The attached patch adds support for GNU platforms, but I can't figure out a nice way to call it for all generated code. Can