search for: getlazybitcodemodul

...n create a .cpp file containing the bitcode, which is compiled into my app. * Before JITing the dynamic code, my app initializes the Module like this: llvm::MemoryBuffer* buf = llvm::MemoryBuffer::getMemBuffer (llvm::StringRef(bitcode, bitcode_size), name); llvm::Module *m = llvm::getLazyBitcodeModule (buf, context(), err); where bitcode is a big char array holding the precompiled bitcode. The idea is to "seed" the module with that precompiled bitcode so that any calls I inserted into the IR will work properly. * When I JIT, I just refer to functions in the bitcode like &quot...

...le, and call ParseBitcodeFile on it at startup. Unfortunately, this parsing takes about 60ms right now, which is the main component of my ~100ms time to run on an empty source file (another ~20ms is loading the pre-jit'd image through an ObjectCache). I thought I'd save some time by using getLazyBitcodeModule, since the IR isn't actually needed right away, but this only reduced the parsing time (ie the time of the actual getLazyBitcodeModule() call) to 45ms, which I thought was surprising. I also tested computing the bytewise-xor of the bitcode file to make sure that it was fully read into memory,...

This is sounding rather like getLazyBitcodeModule is simply incompatible with MCJIT. Can anybody confirm that this is definitely the case? Is it by design, or by omission, or bug? Re your option #1 and #2 -- sorry for the newbie questions, but can you point me to docs or code examples for how the linking or object caching should be achieved? I...

...eFile on it at startup. > > Unfortunately, this parsing takes about 60ms right now, which is the main > component of my ~100ms time to run on an empty source file (another ~20ms > is loading the pre-jit'd image through an ObjectCache). I thought I'd save > some time by using getLazyBitcodeModule, since the IR isn't actually needed > right away, but this only reduced the parsing time (ie the time of the > actual getLazyBitcodeModule() call) to 45ms, which I thought was > surprising. I also tested computing the bytewise-xor of the bitcode file > to make sure that it was ful...

...;>> Unfortunately, this parsing takes about 60ms right now, which is the >>> main component of my ~100ms time to run on an empty source file (another >>> ~20ms is loading the pre-jit'd image through an ObjectCache). I thought >>> I'd save some time by using getLazyBitcodeModule, since the IR isn't >>> actually needed right away, but this only reduced the parsing time (ie the >>> time of the actual getLazyBitcodeModule() call) to 45ms, which I thought >>> was surprising. I also tested computing the bytewise-xor of the bitcode >>> f...

...by 0x97074CE: llvm::StringRef::str() const (StringRef.h:159) ==24227== by 0x970750E: llvm::StringRef::operator std::string() const (StringRef.h:176) ==24227== by 0x9D22519: llvm::Module::Module(llvm::StringRef, llvm::LLVMContext&) (Module.cpp:61) ==24227== by 0x99FCD1D: llvm::getLazyBitcodeModule(llvm::MemoryBuffer*, llvm::LLVMContext&, std::string*) (BitcodeReader.cpp:2641) ==24227== by 0x99FCDF8: llvm::ParseBitcodeFile(llvm::MemoryBuffer*, llvm::LLVMContext&, std::string*) (BitcodeReader.cpp:2660) ==24227== Mismatched free() / delete / delete [] ==24227== at 0x40257ED:...

Thanks for the pointers. Am I correct in assuming that putting the precompiled bitcode into a second module and linking (or using the object caches) would result in ordinary function calls, but would not be able to inline the functions? -- lg On Jan 21, 2014, at 11:55 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would say that the incompatibility is by design. Not

...at 0x501FE3: llvm::BitstreamCursor::Read(unsigned int) (in /home/willy/blah_test_script/new_blah/simple_scev_dynamic_array) ==536== by 0x501A19: llvm::BitcodeReader::ParseBitcodeInto(llvm::Module*) (in /home/willy/blah_test_script/new_blah/simple_scev_dynamic_array) ==536== by 0x50AEC8: llvm::getLazyBitcodeModule(llvm::MemoryBuffer*, llvm::LLVMContext&) (in /home/willy/blah_test_script/new_blah/simple_scev_dynamic_array) ==536== by 0x50B295: llvm::parseBitcodeFile(llvm::MemoryBuffer*, llvm::LLVMContext&) (in /home/willy/blah_test_script/new_blah/simple_scev_dynamic_array) ==536== by 0x4F1231:...

...3: llvm::BitstreamCursor::Read(unsigned int) (in /home/willy/blah_test_script/new_blah/simple_scev_dynamic_array) > ==536== by 0x501A19: llvm::BitcodeReader::ParseBitcodeInto(llvm::Module*) (in /home/willy/blah_test_script/new_blah/simple_scev_dynamic_array) > ==536== by 0x50AEC8: llvm::getLazyBitcodeModule(llvm::MemoryBuffer*, llvm::LLVMContext&) (in /home/willy/blah_test_script/new_blah/simple_scev_dynamic_array) > ==536== by 0x50B295: llvm::parseBitcodeFile(llvm::MemoryBuffer*, llvm::LLVMContext&) (in /home/willy/blah_test_script/new_blah/simple_scev_dynamic_array) > ==536== by...

...lly WOLFF <willy.wolff at etu.unistra.fr>wrote: > The stack trace is: > (gdb) bt > #0 0x00000000004fa8c8 in llvm::BitstreamCursor::Read(unsigned int) () > #1 0x00000000004fa1d2 in llvm::BitcodeReader:: > ParseBitcodeInto(llvm::Module*) () > #2 0x0000000000503ae9 in llvm::getLazyBitcodeModule(llvm::MemoryBuffer*, > llvm::LLVMContext&) () > #3 0x0000000000503eb6 in llvm::parseBitcodeFile(llvm::MemoryBuffer*, > llvm::LLVMContext&) () > #4 0x00000000004ec195 in jitter (skeletons=<optimized out>, > params=0x7fffffffdf40, phi_state=0x11adbc0, lower=0, upper=25...

Hi everyone, In debugging an LLVM based system with a runtime module loaded from bitcode, I ran into a strange error when trying to use getLazyBitcodeModule instead of just ParseBitcodeFile (when loading lazily I get an "Invalid CALL" during bitcode deserialization). I can't decide if this is a "bug" or just a "you shouldn't use Module/Inliner like this". The problem is related to using templates (and thereby lin...

...ss I'm feeling a little doubtful about it. Have you tried using an ObjectCache and pre-jitting [I still have a hard time using that term with a straight face] the runtime module? My runtime isn't that large (about 4kloc), but the numbers I'm getting are that it takes about 2ms for the getLazyBitcodeModule call, and about 4ms to load the stdlib through the ObjectCache. I'm not sure how these numbers scale with the size of the runtime, but it feels like if the ObjectCache loading is too expensive then loading the bitcode might be as well? Another idea is that you could load+jit the bitcode the...

I mad the change, and still have the problem. I investigate more the source code of llvm. First, I change isRawBitcode function to print the content of the parameter like this: original: http://llvm.org/docs/doxygen/html/ReaderWriter_8h_source.html#l00081 inline bool isRawBitcode(const unsigned char *BufPtr, const unsigned char *BufEnd) { // These bytes sort

...functions that the dynamic code *could* call, but any particular JITed program will only call a tiny fraction of that. I pre-compile this library to bitcode at build time, and seed the module with it. If I call llvm::ParseBitcodeFile to pull it in, I incur about a 0.25s overhead. If I use llvm::getLazyBitcodeModule, it's less than 0.01s for small programs, which is fast enough to compile/recompile these functions frequently in an interactive application. I'd very much like to see this kind of gain for MCJIT. I don't care if it's literally part of MCJIT or provided as a wrapper. Either is fi...

...the new JIT and so I first tried to add the ability to load an existing bitcode file, then make calls to functions from that file. That was easy to do starting from the example in Chapter 3 of the Orc JIT tutorial if I used parseBitcodeFile to load in the module, but when I switched over to using getLazyBitcodeModule, I ran into problems: The functions in the loaded module weren't materialized before moveFunctionBody tried to copy the function into a new module in order to JIT them. That then led to an assertion failure. I was able to work around this by creating a new function pass, run by the pass man...

...Module (this=0x101813800) at /Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1578 #8 0x00000001001bf8fb in llvm::BitcodeReader::ParseBitcodeInto (this=0x101813800, M=0x101605dd0) at /Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:1848 #9 0x00000001001bf9ea in llvm::getLazyBitcodeModule (Buffer=0x10181b800, Context=@0x101600290, ErrMsg=0x7fff5fbfc8f0) at /Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:2776 #10 0x00000001001bfa7b in llvm::ParseBitcodeFile (Buffer=0x10181b800, Context=@0x101600290, ErrMsg=0x7fff5fbfc8f0) at /Users/talin/Projects/llvm/lib/Bitcode/Rea...

On Jul 26, 2011, at 8:11 AM, Talin wrote: >> >> If that's true, then it means that we're back to the case where every type has to be fully defined down to the leaf level. > > I'm not sure what you mean. LLVM is perfectly fine with opaque structs so long as you don't "deference" them, GEP into them, need their size, etc. > > Let me try with

hacker cling wrote: > Hello all, > I was playing with LLVM pass. I changed the > lib/Transforms/Hello/Hello.cpp 's content to be my own pass. Then I make > install the pass and use an example test1.c to see whether it works or > not. When I run example using the following command: > clang -emit-llvm test1.c -c -o test1.bc > opt -load

Hello all, I was playing with LLVM pass. I changed the lib/Transforms/Hello/Hello.cpp 's content to be my own pass. Then I make install the pass and use an example test1.c to see whether it works or not. When I run example using the following command: clang -emit-llvm test1.c -c -o test1.bc opt -load ../build_llvm/Debug+Asserts/lib/LLVMHello.so -hello < test1.bc > /dev/null It

Reza Sheykhi <hajishey at msu.edu> writes: > I got the following answers: > > which perl > /usr/bin/perl > > which llvm-config > /usr/local/bin/llvm-config > > which llvm-as > /usr/local/bin/llvm-as > > /usr/bin/llvm-confing --version > bash: /usr/bin/llvm-confing: No such file or directory Uh, there is a typo on the command above, it should be