search for: getbitcodemoduleprovider

...his. I'd be grateful if anyone could tell me what I'm doing wrong or point me at docs or examples covering this topic? The gist of my code is: Module *load_module(char *bitcode_name) { MemoryBuffer *buffer = MemoryBuffer::getFile(bitcode_name, &error_message); ModuleProvider *mp = getBitcodeModuleProvider(buffer, getGlobalContext(), &error_message); if( first_time ) { InitializeNativeTarget(); builder = new EngineBuilder(mp); builder->setEngineKind(EngineKind::JIT); CodeGenOpt::Level opt_level = CodeGenOpt::Default; builder->setOptLevel(opt_level); ex...

...(Type.cpp:1319) by 0x85E656E: llvm::BitcodeReader::ParseTypeTable() (BitcodeReader.cpp:498) by 0x85EDDB1: llvm::BitcodeReader::ParseModule(std::string const&) (BitcodeReader.cpp:1078) by 0x85EF35F: llvm::BitcodeReader::ParseBitcode() (BitcodeReader.cpp:1367) by 0x85EF40B: llvm::getBitcodeModuleProvider(llvm::MemoryBuffer*, std::string*) (BitcodeReader.cpp:2078) by 0x85EF483: llvm::ParseBitcodeFile(llvm::MemoryBuffer*, std::string*) (BitcodeReader.cpp:2094) by 0x839ADFF: main (opt.cpp:432) 160 bytes in 4 blocks are definitely lost in loss record 18 of 20 at 0x4023614: operator new(uns...

...; prevent exceptions being passed on to C callers? > > LLVM doesn't use exceptions in anything that has C bindings, so the > catch isn't needed. It does use 'new' (e.g. LLVMCreateModuleProviderForExistingModule), and also calls C++ functions which in turn use new (e.g. LLVMGetBitcodeModuleProvider -> llvm::getBitcodeModuleProvider), so std::bad_alloc is a possibility (a quick search didn't turn up any "set_new_handler" also). There might also be C++ client code (e.g. overridden virtual functions in custom passes) which might (unintentionally) throw exceptions. Regards, -Ma...

...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 load an entire module at once (e.g. with ParseBitcodeFile) or you can load just the outline and load functions on demand (with getBitcodeModuleProvider). This allows clients to lazily load functions as they are needed instead of loading everything off the disk. The JIT is one example that knows how to use this, it lazily loads functions the first time a function is called or its address is taken. > What is the preferred way to inject...

...anyone could tell me what I'm doing wrong or point me at > docs or examples covering this topic? The gist of my code is: > > Module *load_module(char *bitcode_name) { >   MemoryBuffer *buffer = MemoryBuffer::getFile(bitcode_name, > &error_message); >   ModuleProvider *mp = getBitcodeModuleProvider(buffer, getGlobalContext(), > &error_message); > >   if( first_time ) { >       InitializeNativeTarget(); >       builder = new EngineBuilder(mp); >       builder->setEngineKind(EngineKind::JIT); >       CodeGenOpt::Level opt_level = CodeGenOpt::Default; >       build...

...lt;llvm/ExecutionEngine/ExecutionEngine.h> int main( int argc, char** argv ) { std::string error; llvm::MemoryBuffer *foo_buffer, *bar_buffer; llvm::ModuleProvider *foo_provider, *bar_provider; foo_buffer = llvm::MemoryBuffer::getFile( "foo.bc", &error ); foo_provider = llvm::getBitcodeModuleProvider(foo_buffer,&err); bar_buffer = llvm::MemoryBuffer::getFile( "bar.bc", &error ); bar_provider = llvm::getBitcodeModuleProvider(bar_buffer,&err); llvm::ExecutionEngine *engine; engine = llvm::ExecutionEngine::create( foo_provider ); engine->addModuleProvider( bar_provi...

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 into the Module + JIT? My understanding (perhaps

...9; llvm2/include/llvm/CodeGen/LinkAllCodegenComponents.h:43: undefined reference to `llvm::linkShadowStackGC()' /tmp/cc0b5iTo.o: In function `main': VirementJit.cpp:110: undefined reference to `llvm::sys::PrintStackTraceOnErrorSignal()' VirementJit.cpp:122: undefined reference to `llvm::getBitcodeModuleProvider(llvm::MemoryBuffer*, std::basic_string, std::allocator >*)' /tmp/cc0b5iTo.o: In function `void llvm::cl::opt_storage true>::setValue, std::allocator > >(std::basic_string std::char_traits, std::allocator > const&)': llvm2/include/llvm/Support/CommandLine.h:791: undefined...

...the JIT  > > system and I would mostly have to do the work myself. > > ModuleProvider is a very simple concept.  You can > either load an  > entire module at once (e.g. with ParseBitcodeFile) or you > can load  > just the outline and load functions on demand (with  > getBitcodeModuleProvider).  This allows clients to > lazily load  > functions as they are needed instead of loading everything > off the  > disk.  The JIT is one example that knows how to use > this, it lazily  > loads functions the first time a function is called or its > address is  > taken. &...

Hi, Just wondering -- shouldn't all (C linkage) functions exposed by LLVM-C (and written in C++) be catching std::exception (or "...") to prevent exceptions being passed on to C callers? [OT: Does clang warn about throw statements from within "extern C" functions?] Thanks & Regards, -Mahadevan.

On Aug 3, 2008, at 7:54 AM, Mahadevan R wrote: > Hi, > > Just wondering -- shouldn't all (C linkage) functions exposed by > LLVM-C (and written in C++) be catching std::exception (or "...") to > prevent exceptions being passed on to C callers? LLVM doesn't use exceptions in anything that has C bindings, so the catch isn't needed. > [OT: Does clang warn

...deReader.cpp:580 #12 0x0000000000df230e in llvm::BitcodeReader::ParseModule (this=0x1d75530, ModuleID="receptacle-plug-test.bc") at BitcodeReader.cpp:1142 #13 0x0000000000df39b6 in llvm::BitcodeReader::ParseBitcode (this=0x1d75530) at BitcodeReader.cpp:1389 #14 0x0000000000df8431 in llvm::getBitcodeModuleProvider (Buffer=0x1d754c0, Context=@0x7fffffffdd90, ErrMsg=0x7fffffffd3f0) at BitcodeReader.cpp:2084 #15 0x0000000000df84e3 in llvm::ParseBitcodeFile (Buffer=0x1d754c0, Context=@0x7fffffffdd90, ErrMsg=0x7fffffffd3f0) at BitcodeReader.cpp:2102 #16 0x0000000000de1b76 in llvm::Linker::LoadObject (this=0x7...

On Sep 16, 2008, at 12:17 PM, Thomas B. Jablin wrote: > > ----- "Evan Cheng" <evan.cheng at apple.com> wrote: > >> On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: >> >>> Evan, >>> So, if I understand you correctly, the design you have in mind is >>> to: create a PassManager, pass it to the JIT on construction, and >>>

----- "Evan Cheng" <evan.cheng at apple.com> wrote: > On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: > > > Evan, > > So, if I understand you correctly, the design you have in mind is > > to: create a PassManager, pass it to the JIT on construction, and > > modify runJITOnFunction to run the second PassManager on the > > Function

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