search for: invalidateinstructioncache

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!

...========================================================= --- include/llvm/Target/TargetJITInfo.h (revision 52391) +++ include/llvm/Target/TargetJITInfo.h (working copy) @@ -94,6 +94,11 @@ assert(NumRelocs == 0 && "This target does not have relocations!"); } + /// InvalidateInstructionCache - Before the JIT can run a block of code + // that has been emitted it must invalidate the instruction cache on some + // platforms. + virtual void InvalidateInstructionCache(const void *Addr, unsigned len) {} + /// needsGOT - Allows a target to specify that it would like the //...

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

...16:05, schrieb David Tweed: > | I am curious about JMM->invalidInstructionCache(), which I found in > | lli.cpp implementation. lli.cpp contains also call finalizeObject(), I > | just overlooked it. lli.cpp calls finalizeObject(), which calls > | applyPermissions, which in turn calls invalidateInstructionCache. So why > | lli.cpp does call JMM->invalidInstructionCache() explicitely again ? > > My suspicion is it's a historical development; because different > architectures do or don't actually require cache invalidation the calls have > tended not to be initially put in, then ad...

...g 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 descriptor is loaded correctly in 'JIT::runFunction', instead of assuming the JIT function code is an ODP. Now I'm trying to make the relocation work properly. Using the testca...

Hi all, I tried to modify Kaleidoscope Tutorial (toy.cpp from llvm/examples/Kaleidoscope/Chapter7, LLVM 3.3 release branch) in order to use MCJIT instead of JIT. I get segmentation fault when running toy.cpp with fibonacci example from the tutorial. My modified toy.cpp is in attachment and still works with JIT (when #define USE_MCJIT line is commented out). I read discussions regarding

...05, schrieb David Tweed: > | I am curious about JMM->invalidInstructionCache(), which I found in > | lli.cpp implementation. lli.cpp contains also call finalizeObject(), > | I just overlooked it. lli.cpp calls finalizeObject(), which calls > | applyPermissions, which in turn calls invalidateInstructionCache. So > | why lli.cpp does call JMM->invalidInstructionCache() explicitely again ? > > My suspicion is it's a historical development; because different > architectures do or don't actually require cache invalidation the > calls have tended not to be initially put in, then...

...T 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 descriptor is > loaded correctly in 'JIT::runFunction', instead of assuming the JIT function code is > an ODP. > > Now I'm trying to make the relocation work pro...

...; when I define new function, and this is expected. I am curious about JMM->invalidInstructionCache(), which I found in lli.cpp implementation. lli.cpp contains also call finalizeObject(), I just overlooked it. lli.cpp calls finalizeObject(), which calls applyPermissions, which in turn calls invalidateInstructionCache. So why lli.cpp does call JMM->invalidInstructionCache() explicitely again ? Also I think there is a bug in MCJIT::getPointerToFunction: ... StringRef BaseName = F->getName(); if (BaseName[0] == '\1') ... When BaseName is empty it triggers assertion. For example in Kaleidos...

...ng Errno.cpp for Release build llvm[1]: Compiling Host.cpp for Release build llvm[1]: Compiling IncludeFile.cpp for Release build llvm[1]: Compiling Memory.cpp for Release build /home/prasanth/LLVM_ARM/llvm-target/llvm/lib/System/Memory.cpp: In static member function ‘static void llvm::sys::Memory::InvalidateInstructionCache(const void*, size_t)’: /home/prasanth/LLVM_ARM/llvm-target/llvm/lib/System/Memory.cpp:67: error: ‘__clear_cache’ was not declared in this scope make[1]: *** [/home/prasanth/LLVM_ARM/llvm-target/obj-new/lib/System/Release/Memory.o] Error 1 make[1]: Leaving directory `/home/prasanth/LLVM_ARM/llvm-tar...

...One thing though; it seems a lot of functionality is being foisted onto the client. This is all well and good, but it seems that clients are expected to reinvent the wheel quite a bit for no real purpose - an example is the implementation of getPointerToNamedFunction, allocate{Code,Data}Section and invalidateInstructionCache in lli.cpp. Many clients will just want "a standard implementation that works but can be customised" for many of these functions, and this is currently not available. So they have to copy-paste code from lli.cpp and keep it in sync when bugs gets found. Would it not be nicer to hoist th...

So this is likely just an accident rather than on purpose. There's totally room for that to happen, but it'll be the job of the client and not MCJIT itself. Basically whomever should call dlopen if they want to and it's the problem of the client application (which could be lli as the canonical mcjit example) to link in the correct bits. Make sense? If you can see a use case in

...> llvm[1]: Compiling Host.cpp for Release build > llvm[1]: Compiling IncludeFile.cpp for Release build > llvm[1]: Compiling Memory.cpp for Release build > /home/prasanth/LLVM_ARM/llvm-target/llvm/lib/System/Memory.cpp: In > static member function ‘static void > llvm::sys::Memory::InvalidateInstructionCache(const void*, size_t)’: > /home/prasanth/LLVM_ARM/llvm-target/llvm/lib/System/Memory.cpp:67: > error: ‘__clear_cache’ was not declared in this scope > make[1]: *** > [/home/prasanth/LLVM_ARM/llvm-target/obj-new/lib/System/Release/Memory.o] > Error 1 > make[1]: Leaving directory &gt...

Hi. I have a very quick question. Is the instruction cache flushed by the llvm jit before code in memory is written to or executed? I'm assuming so, but I can't find where in the source code this is happening. In particular I searched for clflush, invd, and wbinvd instructions, but couldn't find them. And if it's not necessary to do this, can you please explain why? (I'm

...Host.cpp for Release build > > llvm[1]: Compiling IncludeFile.cpp for Release build > > llvm[1]: Compiling Memory.cpp for Release build > > /home/prasanth/LLVM_ARM/llvm-target/llvm/lib/System/Memory.cpp: In > > static member function ‘static void > > llvm::sys::Memory::InvalidateInstructionCache(const void*, size_t)’: > > /home/prasanth/LLVM_ARM/llvm-target/llvm/lib/System/Memory.cpp:67: > > error: ‘__clear_cache’ was not declared in this scope > > make[1]: *** > > [/home/prasanth/LLVM_ARM/llvm-target/obj-new/lib/System/Release/Memory.o] > > Error 1 > >...

Hi Dmitri, You might want to try replacing the call to JMM->invalidInstructionCache() with a call to TheExecutionEngine->finalizeObject(). If you are getting a non-NULL pointer from getPointerToFunction but it crashes when you try to call it, that is most likely because the memory for the generated code has not been marked as executable. That happens inside finalizeObject, which also

...LVM. 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 descriptor is > > loaded correctly in 'JIT::runFunction', instead of assuming the JIT function code is > > an ODP. > > > > Now I'm trying to mak...