search for: smallstring

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, *O...

The LLVM Tutorial, https://llvm.org/docs/tutorial/LangImpl01.html provides an excellent introduction to language definition and code generation. I am looking for a similar example that demonstrates how to use SmallString. Even a small test program, ———— #include <llvm/ADT/SmallString.h> int main(int argc, char **argv) { llvm::SmallString<32> str("hello world\n"); printf("%s\n", str.c_str()); return 0; } ———— produces 81 lines of IR. In the same way the tutorials gener...

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 http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140623/223557...

...now if the overall direction and > design are correct. > > Yaron > > > 2015-04-21 0:10 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: >> >> 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 >> >> http://lists....

...t; revised > >> patch. Rather then introduce the raw_char_ostream adapter, this version > >> improves raw_svector_ostream. > >> > >> raw_svector_ostream is now a very lightweight adapter, running without a > >> buffer and fowarding almost anything to the SmallString. This solves > both > >> the performance issue and the information duplication issue. The > SmallString > >> is always up-to-date and can be used at any time. flush() does nothing > and > >> is not required. resync() was kept in this patch as a no-op and will be...

...om Duncan in http://llvm.org/pr23395, here is a > revised patch. Rather then introduce the raw_char_ostream adapter, this > version improves raw_svector_ostream. > > raw_svector_ostream is now a very lightweight adapter, running without a > buffer and fowarding almost anything to the SmallString. This solves both > the performance issue and the information duplication issue. The > SmallString is always up-to-date and can be used at any time. flush() does > nothing and is not required. resync() was kept in this patch as a no-op and > will be removed with its users in a follow-up...

...>> > Yaron >> > >> > >> > 2015-04-21 0:10 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: >> >> >> >> 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-Mo...

...more. In principle one gets the asm with targetMachine->addPassesToEmitFile( PM , *OS , llvm::TargetMachine::CGFT_AssemblyFile ) where *OS is a raw_pwrite_stream. The problem is that I only find use cases of raw_pwrite_stream where the derived class raw_svector_ostream is initialized on a SmallString, like SmallString<128> Str; raw_svector_ostream OS(Str); However, the assembler of the modules could be arbitrary large (not fitting in any finite sized SmallString) What can I do? Thanks, Frank

...requires 64, but we > want to > // make sure that we don't grow the buffer unnecessarily on destruction > (when > // the data is flushed). See the FIXME below. > OS.reserve(OS.size() + 128); > > This solution may be worse than the problem. In total: > > * If the SmallString was less than 128 bytes init() will always(!) heap > allocate. > * If it's more or equal to 128 bytes but upon destruction less than 64 > bytes are left unused it will heap allocate for no reason. > > A careful programmer who did size the SmallString to match its use + small >...

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: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110904/3d011c1a/attachment.html>

...tream adapter, this > version > >> >> improves raw_svector_ostream. > >> >> > >> >> raw_svector_ostream is now a very lightweight adapter, running > without > >> >> a > >> >> buffer and fowarding almost anything to the SmallString. This solves > >> >> both > >> >> the performance issue and the information duplication issue. The > >> >> SmallString > >> >> is always up-to-date and can be used at any time. flush() does > nothing > >> >> and > >...

...mail.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. 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...

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 copy strings out of argv. The only thing to watch out for is the "parsecommandlineoptions" API, which doesn't necessarily own the underlying string pointers. -Chris

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...

...----------------------------------------------------------===// > + > +#ifndef LLVM_SUPPORT_FILEOUTPUTBUFFER_H > +#define LLVM_SUPPORT_FILEOUTPUTBUFFER_H > + > +#include "llvm/Support/DataTypes.h" > +#include "llvm/ADT/StringRef.h" > +#include "llvm/ADT/SmallString.h" > + > +namespace llvm { > + > +class error_code; > +template<class T> class OwningPtr; > + > +/// FileOutputBuffer - This interface provides simple way to create an in-memory > +/// buffer which will be written to a file. During the lifetime of these > +///...

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:

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, should work when debugging a core dump (ie: non-live/not executing any code in the debug process). Note that the StringRef visu...

Are there any rules against using std::string or other parts of stl in llvm?

...o. 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 for string manipulation, the strings are generally very short, so SmallString is better. - Michael Spencer

...bled 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 guess that this is not intended. Maybe it can be fixed by the simple patch attached. Best regards Olaf Krzikalla -------------- next part -------------- Index: lib/Support/APFloat.cpp =========================================...