similar to: Minor bug in raw_svector_ostream

+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

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

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

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

I have read already. Probably not so carefully but do not find any for multiple location option inside namespace. On 25.01.2019 12:33, Aki Tuomi wrote: > You should probably read https://wiki.dovecot.org/SharedMailboxes > > Aki > > On 25.1.2019 9.32, Stepan Khlebalov via dovecot wrote: >> My failure. Replace instance with namespace. >> >> On 25.01.2019 12:27, Aki

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?

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

Hello, in order to compile sppex on my Fedora, I had to do the following changes. Please consider installing them to the main tree. Thanks for your work, Stepan Kasal --- /usr/src/redhat/SPECS/Speex.spec 2006-02-15 13:13:48.000000000 +0100 +++ /usr/src/redhat/SPECS/Speex.spec.new 2006-05-10 11:00:25.000000000 +0200 @@ -6,7 +6,7 @@ Name: %name Version: %ver Release: %rel -Copyright: BSD

On Thu, Jul 28, 2011 at 1:29 PM, Chris Lattner <clattner at apple.com> wrote: > On Jul 28, 2011, at 12:07 PM, Talin wrote: > > Because the stream is a raw_ostream, LLVM types and values can easily be >> printed to the stream without having to convert them to string form. >> >> >> I'm unconvinced that this is worth it at all. This is only going to allow

+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

<div>Thanks for the tip. Our goal is to know that call-limit is triggered. And later analyze this info, maybe do some action.</div><div>Yes, we can parse CDRs or execute AGI script but we do not want inmplement this logic on Asterisk because it can affectš<span>performance.</span></div><div>š</div><div>02.07.2015, 15:31, "jg"

Folks, I'm in the process of updating this page: http://llvm.org/docs/HowToReleaseLLVM.html which had its last review in the middle ages. In particular, I'm removing "dragonegg" from the list of requirements, changing the "build" instructions to use the test-release script (by pointing it to the right doc [1]), and updating the list of requirements. CMake is now

I talked to Chandler about the name "offload_libs" vs "parallel_libs" and he said he thinks "offload" is too narrow of a term for the scope he sees for this subproject. One example he brought up was AVX 512. He thinks that code explicitly targeting CPU parallelism should also be included in this project, even though it doesn't fit in the category of

Hi, all Is there someway ability to insert custom Header to "SIP 486" message, when HANGUP application is invoked? Our use case is to set that Header, when call-limit is reached, to analyze elsewhere, but we do not want to set some custom causecode in HANGUP application because this can confuse a calling equipment.

<div>Is there any chance to create feature request for that useful functionality?</div><div>š</div><div>02.07.2015, 14:03, "Rusty Newton" <rnewton@digium.com>:</div><blockquote type="cite"><div><div><div>On Wed, Jul 1, 2015 at 4:46 AM, <span><<a href="mailto:royj@yandex.ru"

Say, I have the following program:    #include <iostream>    int main(){      std::cout << "hello\n";      return 0;    } After generating llvm bitcode using the following command:       $ clang++ -c -emit-llvm -O -Xclang -disable-llvm-passes a.cpp the bitcode has the following function with define. __cxx_global_var_init    main   

Hi all, I have the below extension defined under sip.conf: [2203] type=friend username=2203 secret=123456 host=192.168.0.164 mailbox=2203 context=intern canreinvite=yes dtmfmode=rfc2833 When trying to register from a softphone installed on a PC behind a nat with IP=192.168.0.164, I got 503 FOrbidden...Does anyone have any idea about what could be the issue? Regards -------------- next part

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