search for: ppcjitinfo

Hi, This is a follow up to my previous email since I have now found out a bit more about what goes wrong. I am generating JIT code that calls a native function, but I get the following assertion telling me that the PC relative jump is too long: /llvm/lib/Target/PowerPC/PPCJITInfo.cpp:206: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out of range!"' I have looked into this a bit further, and everythings seems perfectly all right except for the fact that the 16M block of memory for the JIT c...

Hi, I am trying to generate LLVM code that calls a "native" function in the parent program (the program hosting the JIT). I think that I have figured out how to do this, but I get the following assertion failure when the LLVM code is executed: ../llvm/lib/Target/PowerPC/PPCJITInfo.cpp:206: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out of range!"' I am running LLVM 1.8 and MacOSX Tiger on a PowerPC G4. I have attached a complete, minimal program that reproduces the error and the call-sta...

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!

..._icache_invalidate(const void *Addr, size_t len); -#endif - bool PPCCodeEmitter::runOnMachineFunction(MachineFunction &MF) { assert((MF.getTarget().getRelocationModel() != Reloc::Default || MF.getTarget().getRelocationModel() != Reloc::Static) && Index: lib/Target/PowerPC/PPCJITInfo.h =================================================================== --- lib/Target/PowerPC/PPCJITInfo.h (revision 52391) +++ lib/Target/PowerPC/PPCJITInfo.h (working copy) @@ -41,6 +41,11 @@ /// code. /// virtual void replaceMachineCodeForFunction(void *Old, void *New); + + ///...

Hi Andreas, > /llvm/lib/Target/PowerPC/PPCJITInfo.cpp:206: failed assertion > `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out > of range!"' > ... > So how is this supposed to work? Is it wrong that the memory block for > the JIT code is allocated too far off or sho...

...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 anyone help? Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- --- lib/Target/PowerPC/PPCJITInfo.cpp.orig 2008-06-11 07:12:39 +++ lib/Target/PowerPC/PPCJITInfo.cpp 2008-06-16 08:42:25 @@ -336,6 +336,20 @@ #if (defined(__POWERPC__) || defined (__ppc__) || defined(_POWER)) && \ defined(__APPLE__) sys_icache_invalidate(Addr, len); +#elif defined(__GNUC__) + const size_t LineSize = 3...

Ok, thanks for the reply. > In other words, the code generator needs improving to cope with a jump > to an address that is too far away for a PC-relative jump. Should I file this as a bug? If no one better suited is willing to look at this soon, I am willing to give it a try. Any suggestions? Look at the x86 llvm backend and how gcc does it? Regards, Andreas

> Are you able make calls to well known external functions such as > printf? As far as I known, this capability is well tested on x86 / > Linux. Calling printf works at least on OS X (I'm waiting for a reply whether this works on linux). If I call my native function it fails with PPCJITInfo.cpp:382: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out of range!"' > I am wondering if there is some name mangling issue? Not that I'm aware of. It appears to find the function using module- >get...

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 calculating new addresses for functions which does not make much sense for a native function, at all Greetings, Jan

Hi Jan, > Calling printf works at least on OS X (I'm waiting for a reply > whether this works on linux). If I call my native function it fails > with PPCJITInfo.cpp:382: failed assertion `ResultPtr >= -(1 << 23) && > ResultPtr < (1 << 23) && "Relocation out of range!"' I know nothing about this, but the failed assertion suggests the PPC code generator can't cope with a constant that's bigger than...

Hello, I am currently working with PPC64 JIT support for LLVM. So far I could make function calls work by adding function descriptors in 'lib/Target/PowerPC/PPCJITInfo.h' and adding a virtual method at 'LLVM::TargetJITInfo' that is called within 'JITEmitter::finishFunction' just after 'sys::Memory::InvalidateInstructionCache' to update the Global Mapping with function descriptor instead of the function address. The JIT function descrip...

...li). It sounds like you are working on the old JIT, so I suggest you work instead on getting MC-JIT working on powerpc. Ciao, Duncan. > I am currently working with PPC64 JIT support for LLVM. So far I could make function calls > work by adding function descriptors in 'lib/Target/PowerPC/PPCJITInfo.h' and adding a > virtual method at 'LLVM::TargetJITInfo' that is called within 'JITEmitter::finishFunction' > just after 'sys::Memory::InvalidateInstructionCache' to update the Global Mapping with > function descriptor instead of the function address. The JIT f...

All, The following patch fixes the build 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 (__pp...

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. W...

...onEngine/JIT * removed JIT specific startGVStub()'s functions and finishGVStub() from MachineCodeEmitter, ELFWriter, and MachOWriter classes. * modified include/llvm/Target/TargetJITInfo.h to use JITEmitter rather than MachineCodeEmitter. * modified :- - lib/Target/PowerPC/PPCJITInfo.h - lib/Target/PowerPC/PPCJITInfo.cpp - lib/Target/ARM/ARMJITInfo.cpp - lib/Target/ARM/ARMJITInfo.h - lib/Target/Alpha/AlphaJITInfo.cpp - lib/Target/Alpha/AlphaJITInfo.h - lib/Target/X86/X86JITInfo.h - lib/Target/X86/X86JITInfo.cpp to...

...54 LDFLAGS+=-Wl,-G,-bexpfull +211 # What to pass as -rdynamic flag to g++ +212 #RDYNAMIC := -Wl,-export-dynamic +213 RDYNAMIC := -Wl,-brtl It helped me to proceed lot further with the compilation but i am stuck at assembler error while compiling /usr/llvm/llvm-3.1.src/lib/Target/PowerPC/PPCJITInfo.cpp file. It throws the following error. # pwd /usr/llvm/llvm-3.1.src/lib/Target/PowerPC # gmake llvm[0]: Compiling PPCJITInfo.cpp for Release+Asserts build Assembler: /tmp//ccKtnq1J.s: line 5: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-o...

On 10/23/2012 12:20 PM, Sunil Saggar wrote: > I was able to process further by making some code changes and replacing > export-dynamic with -bexpfull in Makefile.config. Now, i am getting > following error while linking .. > > llvm[3]: Linking Release+Asserts Loadable Module LLVMHello.so What exactly was the linking command? -Krzysztof -- Qualcomm Innovation Center, Inc. is a

...I can call it using EE->runFunction als well as using a CallInst. > Does this work? However, one strange effet remains: if I first call the function using EE->runFunction and then try to call it using a CallInst inside another function I get the old "relocation" error in PPCJITInfo.cpp, again. Using a CallInst first, then runFunction and then a CallInst again works, though. For my project this is probably a non-issue but it might indicate some problem in either my code or LLVM - any ideas? Anyway, thank you all for the helpful comments. I'd surely yielded to desp...

...ific startGVStub()'s functions and > finishGVStub() from MachineCodeEmitter, ELFWriter, and MachOWriter > classes. > * modified include/llvm/Target/TargetJITInfo.h to use JITEmitter > rather than MachineCodeEmitter. > * modified :- > - lib/Target/PowerPC/PPCJITInfo.h > - lib/Target/PowerPC/PPCJITInfo.cpp > - lib/Target/ARM/ARMJITInfo.cpp > - lib/Target/ARM/ARMJITInfo.h > - lib/Target/Alpha/AlphaJITInfo.cpp > - lib/Target/Alpha/AlphaJITInfo.h > - lib/Target/X86/X86JITInfo.h > - lib/Ta...

On Tue, 12 Jun 2007, Jan Rehders wrote: >> 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 the stub)? > > Yes. I create a Function with matching signature,