similar to: Newbie question on codeine for SmallString

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

A very common code pattern in LLVM is SmallString<128> 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

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 >

I've managed to eliminate nearly all uses of std::string from my frontend. About the only ones remaining are all of the occurrences of cl::opt<std::string>. Is it likely that at some point we'll see support for SmallString in the command-line lib? -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL:

+llvm-dev at lists.llvm.org The impact should be 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

Here's a performance testcase for the raw_svector_ostream patch. On my WIndows x64 machine it runs in 1010ms with the current code and in 440ms with the patch applies. Is this OK to commit? 2015-05-02 21:31 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > Following a hint from Duncan in http://llvm.org/pr23395, here is a > revised patch. Rather then introduce the

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

+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

On Thu, May 17, 2012 at 3:25 PM, Nick Kledzik <kledzik at apple.com> wrote: > I now have an implementation of FileOutputBuffer (OutputBuffer was already taken).  The patch supports the functionality listed below and I've tested that it works for lld. > > To implement the FileOutputBuffer, I needed to add some more functions to llvm/Support/FileSystem.h, including: >  

On Sep 4, 2011, at 9:14 PM, Talin wrote: > I've managed to eliminate nearly all uses of std::string from my frontend. About the only ones remaining are all of the occurrences of cl::opt<std::string>. Is it likely that at some point we'll see support for SmallString in the command-line lib? The better fix is to switch cl::opt to allow StringRef: there is no specific reason to

Dear list, I recently tried to add instrumentation to SmallVector for using Address sanitizer to detect cases where references used after they are invalidated. This basic implementation for this is here - https://reviews.llvm.org/D87237 However, in adding/testing this, I did uncover some questionable code. Firstly `SmallString<unsigned>::c_str()` and

r244870 (with the change you requested), thanks! I initially placed the virtual function in header since they were one-liners. The coding standards say that an anchor() function should be supplied, which was indeed missing. Other than required anchor function, why should the virtual functions go in the .cpp? Should I move the empty raw_svector_ostream destructor to the .cpp file too as well?

I wanted to bring this up again. I still try to get access to the assembler of a jit-compiled function/module using llvm 3.8 and later. In 3.8 the interface to addPassesToEmitFile has changed and my old method doesn't work any more. In principle one gets the asm with targetMachine->addPassesToEmitFile( PM , *OS , llvm::TargetMachine::CGFT_AssemblyFile ) where *OS is a

On Sat, Jan 19, 2013 at 8:33 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > There isn't much use of std::string in LLVM because it's simply not > needed. There's very little string manipulation, so StringRef is often > a much better choice. When there is a need for string manipulation, > the strings are generally very short, so SmallString is better.

On 1/19/2013 7:55 PM, Sean Silva wrote: > > Although SmallString is actually pretty inefficient, since it keeps > the string data separate from the "vector" header. I believe libc++'s > std::string actually reuses the pointers in the "vector header" as the > storage for the "small" size, and so in that case std::string is > effectively a very

In r271357 I've committed GDB pretty printer script for the following types - ArrayRef $1 = llvm::ArrayRef of length 3 = {1, 0, 7} - StringRef $2 = "foo\000bar" $3 = "fo" - SmallString $4 = "foo\000bar" - *SmallVector(Impl)* $5 = llvm::SmallVector of length 3, capacity 3 = {1, 0, 7} All of these visualizers are pretty simple, robust,

I now have an implementation of FileOutputBuffer (OutputBuffer was already taken). The patch supports the functionality listed below and I've tested that it works for lld. -------------- next part -------------- A non-text attachment was scrubbed... Name: FileOutputBuffer.patch Type: application/octet-stream Size: 25308 bytes Desc: not available URL:

Hi @llvm, I stumbled over a strange behavior if a float containing a NaN is printed (e.g. in the clang rewriter). The local template method "append" in APFloat.cpp deduces the size from the char array, which for "NaN" is 4 (including the trailing zero). If APFloat::toString is called with a SmallString and then SmallString::str() is called, it returns "NaN\0". I

On Sat, Jan 19, 2013 at 5:20 PM, reed kotler <rkotler at mips.com> wrote: > Are there any rules against using std::string or other parts of stl in llvm? No. You can use any part of the stdlib. There isn't much use of std::string in LLVM because it's simply not needed. There's very little string manipulation, so StringRef is often a much better choice. When there is a need

On Jan 19, 2013, at 6:00 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 1/19/2013 7:55 PM, Sean Silva wrote: >> >> Although SmallString is actually pretty inefficient, since it keeps >> the string data separate from the "vector" header. I believe libc++'s >> std::string actually reuses the pointers in the "vector header"