similar to: [LLVMdev] std::string

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

On 1/19/2013 10:00 PM, Chris Lattner wrote: > On Jan 19, 2013, at 7:04 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >> >> Were the "small n" characteristics the main motivation? > > It is one of the motivations. What were the others? The reason I ask is that STL comes all ready, with containers and algorithms. They may not be optimal for

On Jan 19, 2013, at 7:04 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 1/19/2013 8:36 PM, Chris Lattner wrote: >> >> See: >> http://llvm.org/docs/ProgrammersManual.html#picking-the-right-data-structure-for-a-task > > Were the "small n" characteristics the main motivation? It is one of the motivations. > Memory-wise, STL classes

On 1/21/2013 12:35 AM, Chris Lattner wrote: > > I'm confused here. You're acting as though we don't use the STL. In fact, we do use std::string, std::vector, std::map etc when they are the right solution for the job. I'm trying to understand the reasoning behind the decisions made at the beginning of LLVM. My working assumption is that ADT didn't exist when LLVM

On Jan 20, 2013, at 7:46 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >> It is one of the motivations. > > The reason I ask is that STL comes all ready, with containers and algorithms. They may not be optimal for every task, but they do their job and they are part of the standard. There may be some price to pay in terms of performance/memory usage/etc. for a

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

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:

Sure, I guess that splitting the arrayref/stringref headers out is a fine first step. -Chris > On Jul 5, 2017, at 5:07 PM, Zachary Turner <zturner at google.com> wrote: > > Re-writing StringRef / ArrayRef etc to use the exact same API is a good idea long term, but there's a lot of ugly messy details that need to be dealt with. There's thousands of uses of take_front /

Having watched a similar library go through this exact evolution, I really doubt we want to make any split around "things known to be in C++ in the future"... It turns out that this is nearly impossible to predict and precludes a tremendous amount of useful utilities. For example, there is no indication that the range helpers LLVM provides will ever end up in C++'s standard library,

On Wed, Jul 5, 2017 at 7:14 PM Sean Silva <chisophugis at gmail.com> wrote: > On Wed, Jul 5, 2017 at 6:46 PM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Having watched a similar library go through this exact evolution, I >> really doubt we want to make any split around "things known to be in C++ in >> the future"...

Yes, that proposal makes sense to me: the split would be between things that *are* known to be subsumed into later versions of C++, and therefore are a compatibility library. What do you think about this as an implementation approach: - Rewrite StringRef (et al) to use the exact same APIs as std::string_view. Keep the StringRef name for now. - When cmake detects that C++’17 mode is supported,

On Wed, Jul 5, 2017 at 8:14 PM Zachary Turner <zturner at google.com> wrote: > Is there actually a valid use case for using the entire Support library > though? > > One thing that splitting solves is that I can have StringRef and ArrayRef > split up and committed by tomorrow. The same can't be said for the entire > Support library :) > Huh? I'm asking what is

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

+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 1/19/2013 8:36 PM, Chris Lattner wrote: > > See: > http://llvm.org/docs/ProgrammersManual.html#picking-the-right-data-structure-for-a-task Were the "small n" characteristics the main motivation? Memory-wise, STL classes allow user-defined allocators, so use of things like memory pools should be relatively straightforward. Just wondering... :) -Krzysztof -- Qualcomm

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:

For llvm-dwarfdump we need to handle relocations inside the debug info sections in order to successfully dump the dwarf info including strings. Nick sent out a partial patch that did this not too long ago and I've taken it and gone in a bit of a different direction, but kept the same basic architecture. In place of applying the relocations to the data we've read from disk I'm keeping

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