search for: writebitcodetofile

This function (understandably) takes quite a long time, because it has to go through each function in module and write its binary. But it probably can be parallelized if different threads would write binaries separately, and then merge them together. Is this implemented or planned? Yuri

...include "llvm/Support/MemoryBuffer.h" #include "llvm/Support/Streams.h" /// dummy_function - This is used when linking the LLVM libraries into a dynamic @@ -40,8 +41,10 @@ void dummy_function() { new llvm::ExistingModuleProvider(0); llvm::createVerifierPass(); - llvm::WriteBitcodeToFile(0, llvm::cout); + llvm::CreateBitcodeWriterPass(*llvm::cout); + llvm::WriteBitcodeToFile(0, *llvm::cout); llvm::ParseBitcodeFile(NULL); + llvm::MemoryBuffer::getNewMemBuffer(0); llvm::createInstructionCombiningPass(); llvm::createScalarReplAggregatesPass();

...all I have to say I'm really impressed. LLVM rocks! Unfortunately I've now run into a linker error while trying to optimize the IR or turn it to bitcode and likely due to my very limited experience with c++ I just can't figure out how to resolve it. The linker complains that the llvm::WriteBitcodeToFile function is undefined, although I included llvm/Bitcode/ReaderWriter.h: undefined reference to `llvm::WriteBitcodeToFile(llvm::Module const*, std::basic_ostream<char, std::char_traits<char> >&) I also get the same undefined reference error if I call the llvm::createXXXPass and llv...

..."gcd", mod); Where "FT" is the same as before. And the output produced by the PrintModulePass becomes: ; ModuleID = 'GCDMain' declare i32 @gcd(i32, i32) define i32 @main() { EntryBlock: %tmp = call i32 @gcd(i32 30, i32 50) ret i32 %tmp } But it still fails to WriteBitcodeToFile, and produces the same error as before. I guess I might be missing some attribute, like "extern" in C ... Any Comments? Thanks again for your help, Hamayun On 08/31/2011 07:18 PM, Eli Friedman wrote: > On Wed, Aug 31, 2011 at 10:00 AM, Mian M. Hamayun > <mian-muhammad.hamayu...

...ssembly >> blocks. >> > > Are you adding the support using the new LTO API or using the libLTO C > interfaces? > Perhaps I don't fully understand, but I think the answer is: neither :) What I do is output the module as bitcode with the module summary index added (`llvm::WriteBitcodeToFile`, summary index created with `llvm::ModuleSummaryIndexBuilder`). This is then passed to the system linker. The problems arise with ld.gold + LLVMgold plugin. I am using LLVM 3.9.0. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/ll...

...rgs.begin(), args.end(), "", bi); callInst->setCallingConv(CallingConv::Fast); } } } // Writing modified module to new file. std::ostream *os = new std::ofstream("newfile.bc"); WriteBitcodeToFile(&M, *os); return true; } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100604/4152c602/attachment.html>

...module to the optimization passes (opt). An alternative I have is to programmatically generate the corresponding bitcode file at the right time after finishing the pass in discussion - see, for example, http://stackoverflow.com/questions/13903686/writing-module-to-bc-bitcode-file, methods WriteBitcodeToFile() or WriteModule() . Thank you, Alex

You need to make sure that your bitcode file has a module summary index. You can do that either by creating a WriteBitcodePass with EmitSummaryIndex set to true or by calling WriteBitcodeToFile with a module summary index that you created yourself. It doesn't look like either of those options are hooked up to the c API, though. Peter On Fri, Mar 30, 2018, 00:50 Carlo Kok via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I'm using llvm-c (but if needed can call c++ stu...

...uffer.h" > #include "llvm/Support/Streams.h" > > /// dummy_function - This is used when linking the LLVM libraries into a dynamic > @@ -40,8 +41,10 @@ > void dummy_function() { > new llvm::ExistingModuleProvider(0); > llvm::createVerifierPass(); > - llvm::WriteBitcodeToFile(0, llvm::cout); > + llvm::CreateBitcodeWriterPass(*llvm::cout); > + llvm::WriteBitcodeToFile(0, *llvm::cout); > llvm::ParseBitcodeFile(NULL); > + llvm::MemoryBuffer::getNewMemBuffer(0); > > llvm::createInstructionCombiningPass(); > llvm::createScalarReplAggregatesPass(...

...rror in May 07, but it was just changing Bytecode -> Bitcode. My guess is the Evan's change didn't reach the mirror. Here is the function as it exists in the llvm-gcc-4.0 mirror today: void dummy_function() { new llvm::ExistingModuleProvider(0); llvm::createVerifierPass(); llvm::WriteBitcodeToFile(0, llvm::cout); llvm::ParseBitcodeFile(NULL); ... and in llvm-gcc-4.2: void dummy_function() { new llvm::ExistingModuleProvider(0); llvm::createVerifierPass(); llvm::CreateBitcodeWriterPass(*llvm::cout); llvm::WriteBitcodeToFile(0, *llvm::cout); llvm::ParseBitcodeFile(NULL); llvm::Me...

On Jul 13, 2007, at 9:28 AM, Duncan Sands wrote: > Hi Chris, > >> This is probably a patch that got checked into llvm-gcc4 after devang >> started work on 4.2. Please feel free to update 4.2 to the version >> in >> 4.0. > > no, it doesn't exist in 4.0. hmm. that can not be true. It was applied by Evan on May 07, 2007 to unbreak Apple style builds. -

...rgetTriple(M.getTargetTriple()); ModuleB-->setModuleInlineAsm(M.getModuleInlineAsm()); for (Function &F : M) { if (F.getName() == "My Criterion") ModuleA->getFunctionList().push_back(F); else ModuleB->getFunctionList().push_back(F); } WriteBitcodeToFile(ModuleA, osA); WriteBitcodeToFile(ModuleB, osB); } By doing this I can get two .bc files, but when I open it, for each function I can only get the declaration, but not the definition(function body). Could you give me some comments on how to generate the function definitions? Or any other bett...

...orThinTLO pass or is the writeBitCodePass enough? On Fri, Mar 30, 2018, at 10:02, Peter Collingbourne wrote: > You need to make sure that your bitcode file has a module summary > index. You can do that either by creating a WriteBitcodePass with > EmitSummaryIndex set to true or by calling WriteBitcodeToFile with a > module summary index that you created yourself. It doesn't look like > either of those options are hooked up to the c API, though.> > Peter > > On Fri, Mar 30, 2018, 00:50 Carlo Kok via llvm-dev <llvm- > dev at lists.llvm.org> wrote:>> __ >> I...

I'm using llvm-c (but if needed can call c++ stuff too if nedeed); what's the proper way to emit bitcode with thinlto info so the linker can parallelize ?I'm currently using: unwrap(PMB)->PrepareForThinLTO = b; on the pass manager builder, but that doesn't seem to be enough? -------------- next part -------------- An HTML attachment was scrubbed... URL:

...as before. And the output produced by the > PrintModulePass becomes: > > ; ModuleID = 'GCDMain' > > declare i32 @gcd(i32, i32) > > define i32 @main() { > EntryBlock: >  %tmp = call i32 @gcd(i32 30, i32 50) >  ret i32 %tmp > } > > But it still fails to WriteBitcodeToFile, and produces the same error as > before. If you're still getting the "Referencing function in another module" error, the call isn't referring to a declaration in the same module. -Eli

Hello there, Has anyone here used the recent LIBCLC (current git version) with the recent git version LLVM (3.9)? It seems to me that the libraries are not compiled properly and so the generated GPU kernel code does not have the implementation of OpenCl API. Thanks, Azin -------------- next part -------------- An HTML attachment was scrubbed... URL:

...adding the support using the new LTO API or using the libLTO C >>> interfaces? >>> >> >> Perhaps I don't fully understand, but I think the answer is: neither :) >> What I do is output the module as bitcode with the module summary index >> added (`llvm::WriteBitcodeToFile`, summary index created with >> `llvm::ModuleSummaryIndexBuilder`). This is then passed to the system >> linker. The problems arise with ld.gold + LLVMgold plugin. I am using LLVM >> 3.9.0. >> >> > > > -- > Teresa Johnson | Software Engineer | tejohnson a...

...documentation on how to use DIFactory to generate basic debug info? It seems similar enough to IRBuilder but working with objects (rather than pointers) and that's raising some issues. Also, am I supposed to run the ModuleDebugInfoPrinterPass manually, or it gets printed automatically when I WriteBitcodeToFile? -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm

...output_file> OutMain (GetOutputStream("maingcd.bc")); if (!OutMain) return 1; verifyModule(*ModGCD, PrintMessageAction); verifyModule(*ModMain, PrintMessageAction); PassManager PM; PM.add(createPrintModulePass(&outs())); PM.run(*ModGCD); PM.run(*ModMain); WriteBitcodeToFile(ModGCD, OutGCD->os()); WriteBitcodeToFile(ModMain, OutMain->os()); OutGCD->keep(); OutMain->keep(); delete ModGCD; delete ModMain; return 0; } Module* makeMainModule(LLVMContext& Context, Module &inMod) { // Module Construction Module* mod = new Module...

...           callInst->setCallingConv(CallingConv::Fast); > >                     } > >             } > >         } > > > >        // Writing modified module to new file. > >         std::ostream *os = new std::ofstream("newfile.bc"); > >         WriteBitcodeToFile(&M, *os); Try putting "delete os" here? -Eli >         return true; > >     } > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listi...