search for: format_object_base

...ental > 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 different but more intrusive change to Format.h in format_object_base::print() took 5:6.54. A clean build on the same machine takes about 12 minutes. I tried a few hacks to the CMake to say "don't run tablegen, no matter what, and don't make anything depend on tablegen's output", but I couldn't come up with the right magic. If anyone know...

...e 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 different but more intrusive change to Format.h in >> format_object_base::print() took 5:6.54. A clean build on the same machine >> takes about 12 minutes. >> >> I tried a few hacks to the CMake to say "don't run tablegen, no matter >> what, and don't make anything depend on tablegen's output", but I couldn't >> c...

...char C); - raw_ostream &write(const char *Ptr, size_t Size); + virtual raw_ostream &write(unsigned char C); + virtual raw_ostream &write(const char *Ptr, size_t Size); // Formatted output, see the format() function in Support/Format.h. raw_ostream &operator<<(const format_object_base &Fmt); @@ -297,13 +299,13 @@ /// unbuffered. const char *getBufferStart() const { return OutBufStart; } + /// Install the given buffer and mode. + void SetBufferAndMode(char *BufferStart, size_t Size, BufferKind Mode); + //===--------------------------------------------------------...

Sean, thanks for reminding this, Alp did commit a class derived from raw_svector_ostream conatining an internal SmallString he called small_string_ostream. The commit was reverted after a day due to a disagreement about the commit approval and apparently abandoned. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140623/223393.html

It's that TableGen depends on Support, so if you change one file in support, support gets recompiled into a new static archive, which triggers a rerun of tablegen on all the tablegen inputs, which is extremely slow. On Fri, May 26, 2017 at 5:56 PM Hal Finkel <hfinkel at anl.gov> wrote: > > > On 05/26/2017 07:47 PM, Zachary Turner via llvm-dev wrote: > > Changing a header

I don't think we should make flush virtual. Why do you need to do it? Can't you set up the base class to write to use the tail of the memory region as the buffer? On 24 April 2015 at 06:46, Yaron Keren <yaron.keren at gmail.com> wrote: > Hi, > > Is this what you're thinking about? > The code is not tested yet, I'd like to know if the overall direction and >

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

...char C); - raw_ostream &write(const char *Ptr, size_t Size); + virtual raw_ostream &write(unsigned char C); + virtual raw_ostream &write(const char *Ptr, size_t Size); // Formatted output, see the format() function in Support/Format.h. raw_ostream &operator<<(const format_object_base &Fmt); @@ -483,40 +483,42 @@ /// A raw_ostream that writes to an SmallVector or SmallString. This is a /// simple adaptor class. This class does not encounter output errors. +/// raw_svector_ostream operates without a buffer, delegating all memory +/// management to the SmallString. Thus t...