similar to: Race condition in raw_ostream

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,

> 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

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

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 >

+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

+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

Though it won't actually help to guard this: while (StaticList) - a fence here is needed... On Mon, Dec 26, 2016 at 9:20 AM, Viacheslav Nikolaev < viacheslav.nikolaev at gmail.com> wrote: > Ptr member of ManagedStaticBase is now atomic. > In ManagedStaticBase::RegisterManagedStatic we have such code: > > void *Tmp = Creator(); > > Ptr.store(Tmp,

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

Ptr member of ManagedStaticBase is now atomic. In ManagedStaticBase::RegisterManagedStatic we have such code: void *Tmp = Creator(); Ptr.store(Tmp, std::memory_order_release); DeleterFn = Deleter; // Add to list of managed statics. Next = StaticList; StaticList = this; StaticList is not atomic and not guarded by any fence. The same applies to the members

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?

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, 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 I need to use hypercalls from HVM domain (e.g. HYPERVISOR_add_to_physmap). However, it does not work when I am trying to invoke it from HVM Linux guest. Basically, I don''t see that anything happens on hypervisor''s side. I also grep''ed the guest code for ''vmmcall''/''vmcall'' and did not find anything. Is it possible to do it at all?

On Friday 18 December 2009 13:56, David Greene wrote: > On Friday 18 December 2009 13:53, David Greene wrote: > > > > + void releaseStream() { > > > > + // Delete the stream if needed. Otherwise, transfer the buffer > > > > + // settings from this raw_ostream back to the underlying > > > > stream. + if (!TheStream) > > >

On Dec 16, 2009, at 8:12 AM, David Greene wrote: >>> >>> What, specifically, do you want reviewed before I start checking in? >>> I'll be happy to prepare a patch that shows just that. >> >> I want a patch that does one thing (e.g. implements dbgs(), > > Ok, let's start with that. Here's the patch to add the circular raw_ostream. This

On Tue, May 30, 2017 at 12:52 PM Bob Haarman <llvm at inglorion.net> wrote: > I would like to better understand how you came to conclude that the > tablegen re-runs based on changes in Support are what's causing your build > to be slow and what part specifically is taking all that time. I can do a > clean release + assertions build of LLVM, Clang, compiler-rt and lld in >

On Wednesday 16 December 2009 13:19, Chris Lattner wrote: > + int BufferSize; > + std::vector<char> BufferArray; > + bool DelayOutput; > + std::vector<char>::iterator Cur; > > Please doxygenify these. Ok. > Instead of using a std::vector for BufferArray, please just new[] an array > since it is fixed size. Ok. > Why is BufferSize needed with

On Friday 18 December 2009 17:22, David Greene wrote: > On Friday 18 December 2009 13:56, David Greene wrote: > > On Friday 18 December 2009 13:53, David Greene wrote: > > > > > + void releaseStream() { > > > > > + // Delete the stream if needed. Otherwise, transfer the > > > > > buffer + // settings from this raw_ostream back to