search for: outbufcur

...gt; > > raw_ostream &operator<<(StringRef Str) { > > // Inline fast path, particularly for strings with a known length. > > size_t Size = Str.size(); > > > > // Make sure we can use the fast path. > > if (Size > (size_t)(OutBufEnd - OutBufCur)) > > return write(Str.data(), Size); > > > > if (Size) { > > memcpy(OutBufCur, Str.data(), Size); > > OutBufCur += Size; > > } > > return *this; > > } > > I don’t believe "the is racy” is an appropriate qua...

This code from raw_ostream.h is really racy: raw_ostream &operator<<(StringRef Str) { // Inline fast path, particularly for strings with a known length. size_t Size = Str.size(); // Make sure we can use the fast path. if (Size > (size_t)(OutBufEnd - OutBufCur)) return write(Str.data(), Size); if (Size) { memcpy(OutBufCur, Str.data(), Size); OutBufCur += Size; } return *this; } Of course, one might wonder why someone would need to output to a stream from multiple threads at the same time. But imagine someone might get...

...gt; > > raw_ostream &operator<<(StringRef Str) { > > // Inline fast path, particularly for strings with a known length. > > size_t Size = Str.size(); > > > > // Make sure we can use the fast path. > > if (Size > (size_t)(OutBufEnd - OutBufCur)) > > return write(Str.data(), Size); > > > > if (Size) { > > memcpy(OutBufCur, Str.data(), Size); > > OutBufCur += Size; > > } > > return *this; > > } > > I don’t believe "the is racy” is an appropriate qual...

...e raw_svector_ostream is smart to share the text buffer itself, it's >>>> inefficient keeping two sets of pointers to the same buffer: >>>> >>>> In SmallString: void *BeginX, *EndX, *CapacityX >>>> In raw_ostream: char *OutBufStart, *OutBufEnd, *OutBufCur >>>> >>>> Moreover, at runtime the two sets of pointers need to be coordinated >>>> between the SmallString and raw_svector_ostream using >>>> raw_svector_ostream::init, raw_svector_ostream::pwrite, >>>> raw_svector_ostream::resync and raw...

Could you dig into why: + raw_ostream &write(unsigned char C) override { + grow(1); + *OutBufCur++ = C; + return *this; + } Is 3 times as fast as raw_svector_ostream? I don't see a good reason why that should be any faster than: raw_ostream &operator<<(char C) { if (OutBufCur >= OutBufEnd) return write(C); *OutBufCur++ = C; return *this; } You mig...

...OS.str() >> >> While raw_svector_ostream is smart to share the text buffer itself, it's >> inefficient keeping two sets of pointers to the same buffer: >> >> In SmallString: void *BeginX, *EndX, *CapacityX >> In raw_ostream: char *OutBufStart, *OutBufEnd, *OutBufCur >> >> Moreover, at runtime the two sets of pointers need to be coordinated >> between the SmallString and raw_svector_ostream using >> raw_svector_ostream::init, raw_svector_ostream::pwrite, raw_svector_ostream::resync >> and raw_svector_ostream::write_impl. >> A...

...than > raw_svector_ostream in Release=optimized configuration. > > > 2015-05-02 4:39 GMT+03:00 Sean Silva <chisophugis at gmail.com>: > >> >> Could you dig into why: >> + raw_ostream &write(unsigned char C) override { >> + grow(1); >> + *OutBufCur++ = C; >> + return *this; >> + } >> >> Is 3 times as fast as raw_svector_ostream? I don't see a good reason why >> that should be any faster than: >> >> raw_ostream &operator<<(char C) { >> if (OutBufCur >= OutBufEnd) >&g...

...o write an alias analysis pass for LLVM 3.1. The pass is compiled into a .so library. When I loaded it into opt to perform evaluation with command: opt -load my-so-lib -aa-eval foo.bc the following errors occurred: opt: raw_ostream.cpp:261: void llvm::raw_ostream::flush_nonempty(): Assertion `OutBufCur > OutBufStart && "Invalid call to flush_nonempty."' failed. As stated in the documentation I found on LLVM official website, an alias analysis pass should subclass both Passand AliasAnalysisclass. I used GDB for some debugging, and found why the error emerged. By MyAAn...

...S; raw_svector_ostream OS(S); OS<< ... Use OS.str() While raw_svector_ostream is smart to share the text buffer itself, it's inefficient keeping two sets of pointers to the same buffer: In SmallString: void *BeginX, *EndX, *CapacityX In raw_ostream: char *OutBufStart, *OutBufEnd, *OutBufCur Moreover, at runtime the two sets of pointers need to be coordinated between the SmallString and raw_svector_ostream using raw_svector_ostream::init, raw_svector_ostream::pwrite, raw_svector_ostream::resync and raw_svector_ostream::write_impl. All these functions have non-inlined implementations i...

...s pass for LLVM 3.1. The pass is compiled into a .so library. When I loaded it into opt to perform evaluation with command: > > opt -load my-so-lib -aa-eval foo.bc > > the following errors occurred: > > opt: raw_ostream.cpp:261: void llvm::raw_ostream::flush_nonempty(): Assertion `OutBufCur > OutBufStart && "Invalid call to flush_nonempty."' failed. > > As stated in the documentation I found on LLVM official website, an alias analysis pass should subclass both Pass and AliasAnalysis class. I used GDB for some debugging, and found why the error emerged. &...

...Sean Silva <chisophugis at gmail.com>: > >>>>> > >>>>> > >>>>> Could you dig into why: > >>>>> + raw_ostream &write(unsigned char C) override { > >>>>> + grow(1); > >>>>> + *OutBufCur++ = C; > >>>>> + return *this; > >>>>> + } > >>>>> > >>>>> Is 3 times as fast as raw_svector_ostream? I don't see a good reason > >>>>> why that should be any faster than: > >>>>> &gt...

...t;> >>> >>> 2015-05-02 4:39 GMT+03:00 Sean Silva <chisophugis at gmail.com>: >>> >>>> >>>> Could you dig into why: >>>> + raw_ostream &write(unsigned char C) override { >>>> + grow(1); >>>> + *OutBufCur++ = C; >>>> + return *this; >>>> + } >>>> >>>> Is 3 times as fast as raw_svector_ostream? I don't see a good reason >>>> why that should be any faster than: >>>> >>>> raw_ostream &operator<<(char...

...;> >>>>> > >> >>>>> > >> >>>>> Could you dig into why: > >> >>>>> + raw_ostream &write(unsigned char C) override { > >> >>>>> + grow(1); > >> >>>>> + *OutBufCur++ = C; > >> >>>>> + return *this; > >> >>>>> + } > >> >>>>> > >> >>>>> Is 3 times as fast as raw_svector_ostream? I don't see a good > reason > >> >>>>> why that should...