search for: materializefunct

I have tracing the calls to materializeFunction in the LLVM code in hopes of determining how to properly utilize this function but from my explorations I gather it's just a hook which is called by the JIT system and I would mostly have to do the work myself. What is the preferred way to inject a llvm:Function which contains basic blocks...

Carter Cheng wrote: > I have tracing the calls to materializeFunction in the LLVM code in hopes of determining how to properly utilize this function but from my explorations I gather it's just a hook which is called by the JIT system and I would mostly have to do the work myself. > > What is the preferred way to inject a llvm:Function which contains bas...

Thanks for the reply. I actually managed to resolve this problem mostly to my satisfaction. I suspect based on your description of materializeFunction I may be best served by subclassing the ModuleProvider to do what I want. Thanks again. --- On Mon, 7/6/09, Chris Lattner <clattner at apple.com> wrote: > From: Chris Lattner <clattner at apple.com> > Subject: Re: [LLVMdev] ModuleProvider materializeFunction > To: &quot...

On Jul 4, 2009, at 5:59 AM, Carter Cheng wrote: > I have tracing the calls to materializeFunction in the LLVM code in > hopes of determining how to properly utilize this function but from > my explorations I gather it's just a hook which is called by the JIT > system and I would mostly have to do the work myself. ModuleProvider is a very simple concept. You can either lo...

Hi everyone, I would like to apply the following patch (java-materialize.patch) in order to materialize Java functions in vmkit. The current implementation is not satisfactory because the materializeFunction of a module provider is not supposed to do anything but read the bitcode, which is not the case in Java. In Java, materializing a function Foo can possibly trigger class loading (hence executing Java code), do static initialization of classes that may even invoke Foo. Hence after materializi...

...2b43a mainCompilerStart(j3::JavaThread*) + 586 19 vmjc 0x00000000005b0300 vmkit::Thread::internalThreadStart(vmkit::Thread*) + 528 20 libpthread.so.0 0x00007f4fbbe7c0a2 21 libc.so.6 0x00007f4fbb192d1d clone + 109 This is produced inside the JavaAOTCompiler.h, in method materializeFunction which is called from JavaMethod::compiledPtr. What am I doing wrong? Cheers, David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140307/5b93a76e/attachment.html>

...ing a function pointer. void *FPtr = TheExecutionEngine->getPointerToFunction(LF); // Cast it to the right type (takes no arguments, returns a double) so we // can call it as a native function. double (*FP)() = (double (*)())FPtr; I took a look at getPointerToFunction() and it seems it calls materializeFunction ( is this the run time code generator ? ) where most of the work is done. It would be great if you could point out a good starting place to understand the whole JIT'ing place in the source and relevant documentation (I read the paper about Jello). Also are there any dynamic optimizations th...

On Apr 18, 2008, at 1:40 PM, Nicolas Geoffray wrote: > Hi everyone, > > I would like to apply the following patch (java-materialize.patch) > in order to materialize Java functions in vmkit. The current > implementation is not satisfactory because the materializeFunction > of a module provider is not supposed to do anything but read the > bitcode, which is not the case in Java. In Java, materializing a > function Foo can possibly trigger class loading (hence executing > Java code), do static initialization of classes that may even invoke &g...

...nstruction*>::operator[](unsigned int) + 77 7 lli 0x0000000000850ce0 llvm::BitcodeReader::ParseMetadataAttachment() + 448 8 lli 0x0000000000851043 llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 677 9 lli 0x0000000000854b29 llvm::BitcodeReader::materializeFunction(llvm::Function*, std::string*) + 323 10 lli 0x0000000000c6a073 llvm::JIT::getPointerToFunction(llvm::Function*) + 421 11 lli 0x0000000000c68ae6 llvm::JIT::runFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const...

...ef(unsigned int, llvm::Type const*) + 173 7 llvm-dis 0x000000000052e574 llvm::BitcodeReader::getFnValueByID(unsigned int, llvm::Type const*) + 42 8 llvm-dis 0x000000000051482b llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 11371 9 llvm-dis 0x000000000051574a llvm::BitcodeReader::materializeFunction(llvm::Function*, std::string*) + 284 10 llvm-dis 0x000000000050ddca llvm::BitcodeReader::materializeModule(std::string*) + 210 11 llvm-dis 0x00000000005171b2 llvm::ParseBitcodeFile(llvm::MemoryBuffer*, std::string*) + 74 12 llvm-dis 0x000000000050b894 main + 160 13 libc.so.6 0x00000039cf4...

...+ 173 > 7 llvm-dis 0x000000000052e574 > llvm::BitcodeReader::getFnValueByID(unsigned int, llvm::Type const*) + > 42 > 8 llvm-dis 0x000000000051482b > llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 11371 > 9 llvm-dis 0x000000000051574a > llvm::BitcodeReader::materializeFunction(llvm::Function*, > std::string*) + 284 > 10 llvm-dis 0x000000000050ddca > llvm::BitcodeReader::materializeModule(std::string*) + 210 > 11 llvm-dis 0x00000000005171b2 > llvm::ParseBitcodeFile(llvm::MemoryBuffer*, std::string*) + 74 > 12 llvm-dis 0x000000000050b894 main + 1...

...ing a function pointer. void *FPtr = TheExecutionEngine->getPointerToFunction(LF); // Cast it to the right type (takes no arguments, returns a double) so we // can call it as a native function. double (*FP)() = (double (*)())FPtr; I took a look at getPointerToFunction() and it seems it calls materializeFunction ( is this the run time code generator ? ) where most of the work is done. It would be great if you could point out a good starting place to understand the whole JIT'ing place in the source and relevant documentation (I read the paper about Jello). Also are there any dynamic optimizations th...

...void FunctionPassManager::add(ImmutablePass *IP) { PM->add(IP); } bool FunctionPassManager::run(Function &F) { - Function *mF = MP->getModule()->getNamedFunction(F.getName()); - assert((&F == mF) && "ModuleProvider does not contain this function!"); MP->materializeFunction(&F); return PM->run(F); } -Chris > Chris Lattner wrote: > > >On Wed, 14 Apr 2004, Alex Li wrote: > > > > > >>I'm a cs326 student that uses LLVM for our MP. While some of the COOL > >>program can be run seamlessly, I get the following as...

... 0x000000000052e574 >> llvm::BitcodeReader::getFnValueByID(unsigned int, llvm::Type const*) + >> 42 >> 8   llvm-dis  0x000000000051482b >> llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 11371 >> 9   llvm-dis  0x000000000051574a >> llvm::BitcodeReader::materializeFunction(llvm::Function*, >> std::string*) + 284 >> 10  llvm-dis  0x000000000050ddca >> llvm::BitcodeReader::materializeModule(std::string*) + 210 >> 11  llvm-dis  0x00000000005171b2 >> llvm::ParseBitcodeFile(llvm::MemoryBuffer*, std::string*) + 74 >> 12  llvm-dis  0x0...

...ck this state and perform on-demand instantiation as required. It is worthwhile to consider the LLVM module to be a passive output sink, not an active object. The JIT compiler, by contrast, is an active object, cooperating with its environment via the ModuleProvider interface. Overriding materializeFunction should be useful for on-demand instantiation. — Gordon On Mar 26, 2008, at 17:07, Jonathan S. Shapiro wrote: > Okay, we're starting to dig in, and I've hit a question that will no > doubt seem strange. > > Context: BitC is a polymorphic language. Since it has unboxed val...

I'm a newcomer to llvm, but what you've done so far is very impressive. Llvm is a godsend to anybody who is attempting to implement their own their own language. :-) My company is considering using llvm as the backend for a small matlab-like language for scientific computation; our other option is MSIL. After reading through the documentation, I noticed that llvm seems to have one major

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached

Okay, we're starting to dig in, and I've hit a question that will no doubt seem strange. Context: BitC is a polymorphic language. Since it has unboxed value types, our approach to compiling a polymorphic function is to polyinstantate it -- once for each signature. The name mangling scheme is both stable and reversible. At the site of the use occurrence, we can fully determine the mangled