search for: targetjitinfo

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!

...on what the problem is? The attached patch generalizes it (aKor helped me out). I don't know if Intel needs some kind of cache invalidation too but if it does it could use the same hooks. Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- Index: include/llvm/Target/TargetJITInfo.h =================================================================== --- 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!");...

...hink it would be better to add them to the configure.h.in file. * struct to classes due to link errors include\llvm\CodeGen\IntrinsicLowering.h: struct IntrinsicLowering -> class IntrinsicLowering { public: include\llvm\Type.h: struct Type -> class Type { public: include/llvm/Target/TargetJITInfo.h: struct TargetJITInfo -> class TargetJITInfo { public: --- Paolo Invernizzi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SConstruct URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040926/663d431b/attachment.ksh> ---...

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 descriptor is loaded correctly in 'JIT::runFunction', instead...

...ig snip> class Value; The linker complains about the different parameters types, and raise an unresolved external symbol. I can resolve the iussue a) turning the original struct Value { ... } in class Value { public: .... } b) turning all the class Value; into struct Value; The same is for TargetJITInfo, Type, IntrinsicLowering and others... Suggestions? --- Paolo Invernizzi

...TTI=1 sudo make install According to previous posts to the list, REQUIRE_RTTI=1 should do, but I still get a lot of RTTI-related errors like this while linking "opt": (.data.rel.ro._ZTIN4llvm10X86JITInfoE[typeinfo for llvm::X86JITInfo]+0x10): undefined reference to `typeinfo for llvm::TargetJITInfo' Any ideas? Thanks ahead, Pablo

...2.4M llvm::LoopPass::assignPassManager(llvm::PMStack&, llvm::PassManagerType) 2.4M llvm::LLVMTargetMachine::addPassesToEmitMachineCode (llvm::FunctionPassManager&, llvm::MachineCodeEmitter&, bool) 2.4M llvm::JIT::JIT[in-charge](llvm::ModuleProvider*, llvm::TargetMachine&, llvm::TargetJITInfo&) 2.4M llvm::JIT::create(llvm::ModuleProvider*, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*) 2.4M llvm::FunctionPass::assignPassManager(llvm::PMStack&, llvm::PassManagerType) 2.4M llvm::ExecutionEngine::create(llvm::ModuleProvider*, bool,...

...ision=94719 > > I've attached a new patch which adds a new jump table encoding type to indicate jump > tables are emitted inline. This fixes the problem on the XCore target. > > I can put together a patch to switch over ARM as well but I can't easily test it. After this the TargetJITInfo::hasCustomJumpTables() hook would no longer be needed and could be removed. > > -- > Richard Osborne | XMOS > http://www.xmos.com > > <jt.patch>

...one machine, then sending it to another to > be executed, and references from one buffer to another won't work in > that environment.  So that model needs to continue to work.  If you > want to generalize it so other models work as well, go ahead. Maybe what I should do then is change TargetJITInfo::allocateSeparateGVMemory to allocateGVsWithCode and invert the meaning, since I feel like most users probably just want malloc or something similar. You could then subclass the appropriate TJI class and override that method. Would that be a reasonable API change? No one else calls or overrides...

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

...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 function descriptor is > loaded correctly in 'JIT::runFunction...

...roject?view=rev&revision=94719 I've attached a new patch which adds a new jump table encoding type to indicate jump tables are emitted inline. This fixes the problem on the XCore target. I can put together a patch to switch over ARM as well but I can't easily test it. After this the TargetJITInfo::hasCustomJumpTables() hook would no longer be needed and could be removed. -- Richard Osborne | XMOS http://www.xmos.com -------------- next part -------------- A non-text attachment was scrubbed... Name: jt.patch Type: text/x-patch Size: 4312 bytes Desc: not available URL: <http://lists.ll...

...to include/llvm/ExecutionEngine/JIT * moved lib/ExecutionEngine/JIT/JITDwarfEmitter.h to include/llvm/ExecutionEngine/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/...

...t; >> I've attached a new patch which adds a new jump table encoding type to indicate jump >> tables are emitted inline. This fixes the problem on the XCore target. >> >> I can put together a patch to switch over ARM as well but I can't easily test it. After this the TargetJITInfo::hasCustomJumpTables() hook would no longer be needed and could be removed. >> >> -- >> Richard Osborne | XMOS >> http://www.xmos.com >> >> <jt.patch> >> > -- Richard Osborne | XMOS http://www.xmos.com

...:assignPassManager(llvm::PMStack&, > llvm::PassManagerType) > 2.4M llvm::LLVMTargetMachine::addPassesToEmitMachineCode > (llvm::FunctionPassManager&, llvm::MachineCodeEmitter&, bool) > 2.4M llvm::JIT::JIT[in-charge](llvm::ModuleProvider*, > llvm::TargetMachine&, llvm::TargetJITInfo&) > 2.4M llvm::JIT::create(llvm::ModuleProvider*, std::basic_string<char, > std::char_traits<char>, std::allocator<char> >*) > 2.4M llvm::FunctionPass::assignPassManager(llvm::PMStack&, > llvm::PassManagerType) > 2.4M llvm::ExecutionEngine::create(llvm::Modu...

On Mar 1, 2010, at 4:09 PM, Richard Osborne wrote: > On 01/03/10 21:14, Chris Lattner wrote: >> On Mar 1, 2010, at 10:52 AM, Richard Osborne wrote: >> >>> On 23/02/10 14:58, Richard Osborne wrote: >>> >>>> I've recently changed the XCore target to implement BR_JT as a jump to a >>>> series jumps. The jump table entries are

...> * moved lib/ExecutionEngine/JIT/JITDwarfEmitter.h to include/ > llvm/ExecutionEngine/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/A...

Hi everyone, vmkit requires to know the size of a jitted method before emitting the method. This allows to allocate the correct size for the method. The attached patch creates this functionality when the flag SizedMemoryCode is on. In order to implement this functionality, i had to virtualize some MachineCodeEmitter functions. Is it OK to commit the patch? Thanks, Nicolas --------------

....h" >> +#include "llvm/CodeGen/MachineJumpTableInfo.h" >> +#include "llvm/CodeGen/MachineRelocation.h" >> +#include "llvm/ExecutionEngine/GenericValue.h" >> +#include "llvm/Target/TargetData.h" >> +#include "llvm/Target/TargetJITInfo.h" >> +#include "llvm/Target/TargetMachine.h" >> +#include "llvm/Target/TargetOptions.h" >> +#include "llvm/Support/Debug.h" >> +#include "llvm/Support/MutexGuard.h" >> +#include "llvm/System/Disassembler.h" >&g...

.../MachineConstantPool.h" > +#include "llvm/CodeGen/MachineJumpTableInfo.h" > +#include "llvm/CodeGen/MachineRelocation.h" > +#include "llvm/ExecutionEngine/GenericValue.h" > +#include "llvm/Target/TargetData.h" > +#include "llvm/Target/TargetJITInfo.h" > +#include "llvm/Target/TargetMachine.h" > +#include "llvm/Target/TargetOptions.h" > +#include "llvm/Support/Debug.h" > +#include "llvm/Support/MutexGuard.h" > +#include "llvm/System/Disassembler.h" > +#include "llvm/...