search for: write_impl

...t the same time. > > > > But imagine someone might get logs to dbgs() or errs() running the > backend for a target in multiple threads. > > These are unbuffered, I wouldn’t expect a race in the code you list above. > I believe it’ll always forward directly to raw_fd_ostream::write_impl(), > which is calling the libc ::write(). > > — > Mehdi > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -------------- next part -------------- A...

...pacityX 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 in raw_ostream.cpp. Finally, this may cause subtle bugs if S is modified without calling OS::resync(). This is too easy to do by mistake. In this frequent case usage the client does not really care about S being a SmallString with its many use...

> On Dec 7, 2016, at 10:27 AM, Viacheslav Nikolaev <viacheslav.nikolaev at gmail.com> wrote: > > > I believe it’ll always forward directly to raw_fd_ostream::write_impl(), which is calling the libc ::write(). > > Do you mean raw_fd_ostream somehow overrides the operator<< the code for which I extracted? > I cannot see if that is so. And I really saw it didn't albeit in a very old master. No, I meant I didn’t see the race in the code you showed...

...t 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 raw_svector_ostream::write_impl called from > raw_svector_ostream::~raw_svector_ostream. > The issue is already documented: > > raw_svector_ostream::~raw_svector_ostream() { > // FIXME: Prevent resizing during this flush(). > flush(); > } > > And a solution is provided in raw_svector_ostream::init()...

...cifically is taking all that time. I can do a > clean release + assertions build of LLVM, Clang, compiler-rt and lld in > about 5 minutes, plus 40 seconds to run cmake, on what I think is similar > hardware to what Zach is using. If I swap Ptr += ret and Size -= Ret in > raw_fd_ostream::write_impl so that Support changes, I can do an incremental > build in about 10 seconds, including the regeneration of various .inc > files. How do we get from there to 10 minutes for an incremental build? > For the sake of comparison, I made the same change and it took 1:58.39. A slightly differe...

.../// Cur - Pointer to the current output point in BufferArray. + /// + char *Cur; + + /// printLog - Dump the contents of the buffer to Stream. + /// + void printLog(void) { + TheStream->write(BufferArray, BufferSize); + Cur = BufferArray; + } + + virtual void write_impl(const char *Ptr, size_t Size); + + /// current_pos - Return the current position within the stream, + /// not counting the bytes currently in the buffer. + virtual uint64_t current_pos() { + // This has the same effect as calling TheStream.current_pos(), + // but that interface...

..._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 raw_svector_ostream::write_impl called from >>> raw_svector_ostream::~raw_svector_ostream. >>> The issue is already documented: >>> >>> raw_svector_ostream::~raw_svector_ostream() { >>> // FIXME: Prevent resizing during this flush(). >>> flush(); >>> } >>&gt...

.../// Cur - Pointer to the current output point in BufferArray. + /// + char *Cur; + + /// printLog - Dump the contents of the buffer to Stream. + /// + void printLog(void) { + TheStream->write(BufferArray, BufferSize); + Cur = BufferArray; + } + + virtual void write_impl(const char *Ptr, size_t Size); + + /// current_pos - Return the current position within the stream, + /// not counting the bytes currently in the buffer. + virtual uint64_t current_pos() { + // This has the same effect as calling TheStream.current_pos(), + // but that interface...

...with the vector? Isn't it always the size of > BufferArray? Also, why is it signed? Well, you need it with a new[]'d array. :) It's signed because running loops with signed induction variables is better than with unsiged induction variables. In this case it's moot because ::write_impl is passed a size_t anyway. It's just learned habit by me to make anything having to do with induction variables signed. I'll make it unsigned. > What does DelayOutput do? Even reading the code, I don't really understand > what it is doing. Originally it told the stream wheth...

.../// Cur - Pointer to the current output point in BufferArray. + /// + char *Cur; + + /// printLog - Dump the contents of the buffer to Stream. + /// + void printLog(void) { + TheStream->write(BufferArray, BufferSize); + Cur = BufferArray; + } + + virtual void write_impl(const char *Ptr, size_t Size); + + /// current_pos - Return the current position within the stream, + /// not counting the bytes currently in the buffer. + virtual uint64_t current_pos() { + // This has the same effect as calling TheStream.current_pos(), + // but that interface...

...cifically is taking all that time. I can do a > clean release + assertions build of LLVM, Clang, compiler-rt and lld in > about 5 minutes, plus 40 seconds to run cmake, on what I think is similar > hardware to what Zach is using. If I swap Ptr += ret and Size -= Ret in > raw_fd_ostream::write_impl so that Support changes, I can do an incremental > build in about 10 seconds, including the regeneration of various .inc > files. How do we get from there to 10 minutes for an incremental build? > Which build system are you using? On my build config (16 core/32 thread, 128GB RAM) it take...

...e. I can do a >>> clean release + assertions build of LLVM, Clang, compiler-rt and lld in >>> about 5 minutes, plus 40 seconds to run cmake, on what I think is similar >>> hardware to what Zach is using. If I swap Ptr += ret and Size -= Ret in >>> raw_fd_ostream::write_impl so that Support changes, I can do an incremental >>> build in about 10 seconds, including the regeneration of various .inc >>> files. How do we get from there to 10 minutes for an incremental build? >>> >> >> For the sake of comparison, I made the same change...

.../// Cur - Pointer to the current output point in BufferArray. + /// + char *Cur; + + /// printLog - Dump the contents of the buffer to Stream. + /// + void printLog(void) { + TheStream->write(BufferArray, BufferSize); + Cur = BufferArray; + } + + virtual void write_impl(const char *Ptr, size_t Size); + + /// current_pos - Return the current position within the stream, + /// not counting the bytes currently in the buffer. + virtual uint64_t current_pos() { + // This has the same effect as calling TheStream.current_pos(), + // but that interface...

On Dec 16, 2009, at 8:12 AM, David Greene wrote: >>> >>> What, specifically, do you want reviewed before I start checking in? >>> I'll be happy to prepare a patch that shows just that. >> >> I want a patch that does one thing (e.g. implements dbgs(), > > Ok, let's start with that. Here's the patch to add the circular raw_ostream. This

...small as all the other streamers usually write directly to the memory buffer and only when out of buffer they call write(). OTOH, raw_svector_ostream (without a buffer) goes though write for every character or block it writes. It can work without virtual write() by overriding the existing virtual write_impl() but this is a slower code path for raw_svector_ostream. Even though the attached raw_svector_ostream patch without virtual write() is still significantly faster then the current raw_svector_ostream since it avoids the double buffering. With this patch, on my system the example runs at 750ms comp...

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);

...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 in >> raw_ostream.cpp. >> >>>> >> >>>> Finally, this may cause subtle bugs if S is modified without calling >> >>>> OS::resync(). This is too easy to do by mis...

Hi all, In a pass I’m using raw_fd_ostream to write a string to a file. Does raw_fd_ostream guarantee the write is atomic when I do parallel compilation (currently I’m using -j8)? I have some errs() to print information for debugging purposes and I saw that the printed information gets messed up sometime. If I’m writing a string with the format of “A:B:C”, is it possible that I got “A1:B2:C1” and

...>>>> 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 in raw_ostream.cpp. >>>> >>>> Finally, this may cause subtle bugs if S is modified without calling >>>> OS::resync(). This is too easy to do by mistake. >>>> >>>> In th...

...*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 in raw_ostream.cpp. >> >> Finally, this may cause subtle bugs if S is modified without calling >> OS::resync(). This is too easy to do by mistake. >> >> In this frequent case usage the client does not reall...