search for: f_binary

Hi - attached is a patch to enable building DragonEgg (x86_64) for LLVM3.3 and LLVM3.4. That is, add these changes to the 3.3 release, and it becomes possible to build DragonEgg against a llvm3.4 compiler. Regards, Richard Gorton Cognitive Electronics rcgorton at cog-e.com ---------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

...In this specific case, however, I think that the API breakage was completely unneccessary and could have easily been avoided right from the beginning. In fact, you could have just taken the LLVM 2.5 raw_fd_ostream constructor, turned the 'bool Binary' into an 'unsigned flags' (with F_Binary=1 for backward compatibility, other flags added as needed) and old code would have just continued to work and new code would have been happy, too. But that's not what happened. Instead we now have a mess of three different raw_fd_ostream interfaces with almost identical functionality in three c...

On Aug 25, 2009, at 3:40 PM, Albert Graef wrote: > Albert Graef wrote: >> I understand that. But in this specific case it would be very easy to >> maintain, no? > > FWIW, suggested patch attached. That makes the LLVM 2.5 style > raw_fd_ostream constructor work with the trunk (r80036). Note that > this > just adds a second constructor, existing code will continue to

I'm using the LLVM C++ API to create code on-the-fly for execution. This works fine. But what if I want to save this code to disk, quit, relaunch my app at some later time, reload the previously generated code off disk, and execute it? How can I do that? Can somebody point me to some documentation or examples? Thanks. - Paul

Albert Graef wrote: > I understand that. But in this specific case it would be very easy to > maintain, no? FWIW, suggested patch attached. That makes the LLVM 2.5 style raw_fd_ostream constructor work with the trunk (r80036). Note that this just adds a second constructor, existing code will continue to work as before. I'd be happy to prepare an analogous patch for the 2.6 release

...y way: you either try to keep it or not. If not, I don't think that trying to paper over small changes like this is worth it. > In fact, you could have just taken the LLVM 2.5 > raw_fd_ostream constructor, turned the 'bool Binary' into an 'unsigned > flags' (with F_Binary=1 for backward compatibility Sure, but again, the change wasn't made for an arbitrary reason: moving them to the end allows them to be optional, so that they do not need to be specified. This makes the API more elegant. I'm not willing to sacrifice small bits of API elegance unless...

...------- Module* makeLLVMModule(LLVMContext& Context); Module* makeMainModule(LLVMContext& Context, Module &inMod); static tool_output_file *GetOutputStream(const char *FileName) { std::string error; tool_output_file *FDOut = new tool_output_file(FileName, error, raw_fd_ostream::F_Binary); if (!error.empty()) { errs() << error << '\n'; delete FDOut; return 0; } return FDOut; } int main(int argc, char**argv) { LLVMContext& Context = getGlobalContext(); Module* ModGCD = makeLLVMModule(Context); Module* ModMain = makeMainMod...

..._program)() = (int32_t(*)())(intptr_t)(main_fp); std::cout << "Ready..." << std::endl; return target_program(); #if 0 // Write a bitcode file and interpret it. { std::string err; llvm::raw_fd_ostream fout("sprite-out.bc", err, llvm::raw_fd_ostream::F_Binary); llvm::WriteBitcodeToFile(module_stab.module_ir.ptr(), fout); } std::system("llvm-link-3.3 sprite-out.bc " SPRITE_LIBINSTALL "/sprite-rt.bc > tmp.bc"); std::system("mv tmp.bc sprite-out.bc"); int const status = std::system("lli-3.3 sprite-out.bc&qu...

..."Ready..." << std::endl; > > return target_program(); > > #if 0 > > // Write a bitcode file and interpret it. > > { > > std::string err; > > llvm::raw_fd_ostream fout("sprite-out.bc", err, > llvm::raw_fd_ostream::F_Binary); > > llvm::WriteBitcodeToFile(module_stab.module_ir.ptr(), fout); > > } > > std::system("llvm-link-3.3 sprite-out.bc " SPRITE_LIBINSTALL > "/sprite-rt.bc > tmp.bc"); > > std::system("mv tmp.bc sprite-out.bc"); > > i...

...eturn target_program(); > > > > #if 0 > > > > // Write a bitcode file and interpret it. > > > > { > > > > std::string err; > > > > llvm::raw_fd_ostream fout("sprite-out.bc", err, > > llvm::raw_fd_ostream::F_Binary); > > > > llvm::WriteBitcodeToFile(module_stab.module_ir.ptr(), fout); > > > > } > > > > std::system("llvm-link-3.3 sprite-out.bc " SPRITE_LIBINSTALL > > "/sprite-rt.bc > tmp.bc"); > > > > std::system("m...

...; + return false; +} + +/// Optimize merged modules using various IPO passes +bool LTOCodeGenerator::generateObjectFile(Module *Mod, const char *FN, + std::string &errMsg) { + std::string errFile; + tool_output_file OutFile(FN, errMsg, raw_fd_ostream::F_Binary); + + if (!errFile.empty()) { + errMsg += errFile; return true; } + OutFile.keep(); - // Run our queue of passes all at once now, efficiently. - passes.run(*mergedModule); + formatted_raw_ostream OS(OutFile.os()); + bool Fail = performPostLTO(Mod, OS, errMsg); + OutFile.os().cl...