search for: buffer_ostream

I can use llc to compile my IR module to amdgcn with some non-zero output. However, if try to write the output (assembly or object) to a string (via buffer_ostream) the resulting string has always zero length. Here the code changes I do: Original llc:       if (Target->addPassesToEmitFile(PM, *OS,                                       DwoOut ? &DwoOut->os() : nullptr,                                       FileType, NoVerify, MMIWP)) Now, wit...

...port/raw_ostream.h:321:7: warning: 'raw_pwrite_stream' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [-Wweak-vtables] class raw_pwrite_stream : public raw_ostream { ^ ../include/llvm/Support/raw_ostream.h:539:7: warning: 'buffer_ostream' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [-Wweak-vtables] class buffer_ostream : public raw_svector_ostream { However, I do wonder how useful my patch for Instructions.h (and constants.h too which needed work), when you can’t #i...

...fo(TripleName, MCPU, FeaturesStr)); OK, that seems, OK. Now I want to setup an output buffer: std::string ofile("/home/users/avose/hpcgp/hpcgp_rundir/tmp.o"); std::unique_ptr<tool_output_file> Out = GetOutputStream(ofile); if (!Out) { return 1; } std::unique_ptr<buffer_ostream> BOS; raw_pwrite_stream *OS = &Out->os(); if (!Out->os().supportsSeeking()) { BOS = make_unique<buffer_ostream>(Out->os()); OS = BOS.get(); } This also seems to do OK. Now I would think I can finally get around to making the code emitter and the MCStreamer:...

...21:7: warning: 'raw_pwrite_stream' has no out-of-line virtual method > definitions; its vtable will be emitted in every translation unit [-Wweak-vtables] > class raw_pwrite_stream : public raw_ostream { > ^ > ../include/llvm/Support/raw_ostream.h:539:7: warning: 'buffer_ostream' has no out-of-line virtual method definitions; > its vtable will be emitted in every translation unit [-Wweak-vtables] > class buffer_ostream : public raw_svector_ostream { > > However, I do wonder how useful my patch for Instructions.h (and constants.h too which needed work...

...ev/2014-June/074145.html I’m also aware of the alternative approach below, but I’m not sure if the output will be the same as the assembly generated by OrcJit. Probably not. std::string outStr; { llvm::legacy::PassManager pm; llvm::raw_string_ostream stream(outStr); llvm::buffer_ostream pstream(stream); targetMachine->addPassesToEmitFile(pm, pstream, nullptr, llvm::TargetMachine::CGFT_AssemblyFile); pm.run(*m); } llvm::errs() << "Assembly:\n" << outStr << "\n"; Thanks! Diego ___...

On Fri, Aug 7, 2015 at 10:22 AM, Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Aug 6, 2015 at 12:04 PM, David Chisnall via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > [Ooops, sent to the old list address by mistake] > > > > On 30 Jul 2015, at 21:04, tom at stellard.net wrote: > >> > >> For flags like

+update diff 2015-05-02 7:38 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > I outlined (is that the right > word?) raw_char_ostream::grow, raw_char_ostream::write (both) into > raw_ostream.cpp with less than 10% difference in performance. > > Profiling reveals that the real culprit is the code line > > OS.reserve(OS.size() + 64); > > called from

...StringRef - /// for the vector contents. - StringRef str(); + /// Return a StringRef for the vector contents. + StringRef str() { return StringRef(OS.data(), OS.size()); } }; /// A raw_ostream that discards all output. @@ -539,9 +541,7 @@ SmallVector<char, 0> Buffer; public: - buffer_ostream(raw_ostream &OS) : raw_svector_ostream(Buffer, 0), OS(OS) { - init(); - } + buffer_ostream(raw_ostream &OS) : raw_svector_ostream(Buffer), OS(OS) {} ~buffer_ostream() { OS << str(); } }; Index: lib/Support/raw_ostream.cpp ====================================================...