similar to: [LLVMdev] SmallString + raw_svector_ostream combination should be more efficient

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

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

+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

+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

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?

> 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

Ok, one more issue. I've removed the no-op resync() method and now getting rid of numerous raw_ostream::flush() calls. These were required before but now will never do anything but will waste runtime discovering that. To find raw_svector_ostream::flush() calls speficially I locally shadowed raw_ostream:flush() with a deleted flush(): class raw_svector_ostream { ... public: ... void flush()

On Wed, Dec 7, 2016 at 10:02 AM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Dec 7, 2016, at 1:52 AM, Viacheslav Nikolaev via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > This code from raw_ostream.h is really racy: > > > > raw_ostream &operator<<(StringRef Str) { > > // Inline fast path,

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

I've been curious for a while whether SmallVectors have the right speed/memory tradeoff. It would be straightforward to shave off a couple of pointers (1 pointer/4B on 32-bit; 2 pointers/16B on 64-bit) if users could afford to test for small-mode vs. large-mode. The current scheme works out to something like this: ``` template <class T, size_t SmallCapacity> struct SmallVector { T

In SmallVector.h: class SmallVectorBase { *protected:* void *BeginX, *EndX, *CapacityX; *protected:* SmallVectorBase(void *FirstEl, size_t Size) : BeginX(FirstEl), EndX(FirstEl), CapacityX((char*)FirstEl+Size) {} In StringMap.h: class StringMapImpl { *protected:* // Array of NumBuckets pointers to entries, null pointers are holes. // TheTable[NumBuckets] contains a sentinel value

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

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,

Hi, I am now trying to write an alias analysis pass for LLVM 3.1. The pass is compiled into a .so library. When I loaded it into opt to perform evaluation with command: opt -load my-so-lib -aa-eval foo.bc the following errors occurred: opt: raw_ostream.cpp:261: void llvm::raw_ostream::flush_nonempty(): Assertion `OutBufCur > OutBufStart && "Invalid call to

Hi Mehdi, Thanks for your reply. It seems caused by random rename because I saw %struct.StructTyName.692.475*, which might be twice renaming. Does this collision occur because this type is declared more than once? I encountered this problem when used clang to compile transmission 1.42 (http://download.transmissionbt.com/files/) with configuration: "./configure --disable-gtk". Then

I tried to compare two types. Because of renaming, the comparison result is not as expected. How to deal with renaming while comparing types? Best, Haopeng On 6/2/15 4:09 PM, Mehdi Amini wrote: > Hi Haopeng, > > One more element, I just noticed you are using LTO, I am not sure how it is implemented but my guess is that there is a shared LLVMContext. If multiple files include this

Hi, Does your pass use multiple inheritance? Sounds like your problem is that you need to define getAdjustedAnalysisPointer, see: http://llvm.org/docs/doxygen/html/classllvm_1_1Pass.html#a03d3a81b1c46aff7c38ef3a6750ba225 An example implementation (very likely exactly what you want) is in LibCallAliasAnalysis: http://llvm.org/docs/doxygen/html/LibCallAliasAnalysis_8h_source.html#l00060 Hope

Hi All, I generated the following code with "clang -flto" command. void test(struct StruTyName *a) { ... } Then the type of test function is "void (%struct.StruTyName.100*)" by calling function::getFunctionType API. What's the meaning of number 100? Best, Haopeng