search for: shared_ptr

why llvm contains IntrusiveRefCntPtr instead of using only std::shared_ptr? IntrusiveRefCntPtr widely used in llvm and clang source code. Due to better performance? for example in main func of clang frontend: int cc1_main(ArrayRef<const char *> Argv, const char *Argv0, void *MainAddr) { ensureSufficientStack(); std::unique_ptr<CompilerInstance> Clang(n...

...lt;cschneider at radiodata.biz> wrote: >> >> Hello, >> I just discovered, that, when using enable_shared_from_this and >> inheriting it privately, this fails at runtime. >> I made a small example: >> >> #include <memory> >> #include <boost/shared_ptr.hpp> >> #include <boost/make_shared.hpp> >> #include <boost/enable_shared_from_this.hpp> >> >> #ifndef prefix >> #define prefix std >> #endif >> >> class foo: >> prefix::enable_shared_from_this<foo> >> { >>...

Hi, In the code below, MyNamespace::MyClass_ptr will be named "struct.boost::MyClass_ptr" by llvm-g++, and not "struct.MyNamespace::MyClass_ptr" as I expected. I observed this with the real boost::shared_ptr but used the code below (also attached as structnametest1.cc) on the demo page (http://llvm.org/demo/index.cgi) to reproduce the behavior. When I extended my test code to create a MyClass and MyClass_ptr in the boost namespace too, it seems like both struct:s get called "struct.boost::MyClass...

On Wed, Oct 19, 2016 at 6:24 PM, Benjamin Kramer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > In terms of performance shared_ptr has a number of disadvantages. One > is that it always uses atomics even though most IntrusiveRefCntPtrs > are used in single-threaded contexts. Another is weak_ptr adding a lot > of complexity to the implementation, IntrusiveRefCntPtr doesn't > support weak references. > > Wi...

Hi, I would like to use std::shared_ptr in my pass. However I'm facing a problem wrt RTTI. If I have a code like: std::shared_ptr<BaseClass> x(new DerivedClass()); ... std::shared_ptr<DerivedClass> p = std::dynamic_pointer_cast<DerivedClass>(x); It does not compile since the default RTTI infrastructure is not used...

Hello, I just discovered, that, when using enable_shared_from_this and inheriting it privately, this fails at runtime. I made a small example: #include <memory> #include <boost/shared_ptr.hpp> #include <boost/make_shared.hpp> #include <boost/enable_shared_from_this.hpp> #ifndef prefix #define prefix std #endif class foo: prefix::enable_shared_from_this<foo> { public: prefix::shared_ptr<foo> get_sptr() { return shared_from_this();...

In the most basic case, I'd imagine something like this: auto C = std::make_shared<LLVMContext>(); struct ModuleAndSharedContextDeleter { std::shared_ptr<LLVMContext> C; operator()(Module *M) { delete M; } /* ctor to init C */}; std::unique_ptr<Module, ModuleAndSharedDeleter> M(new Module(C.get()), ModuleAndSharedContextDeleter(C)); (or invert this and traffic in structs that have a unique_ptr<Module> and a shared_ptr<LLVMConte...

...t lists.llvm.org> wrote: > > On Oct 19, 2016, at 11:14 AM, Bruce Hoult via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On Wed, Oct 19, 2016 at 6:24 PM, Benjamin Kramer via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> In terms of performance shared_ptr has a number of disadvantages. One >> is that it always uses atomics even though most IntrusiveRefCntPtrs >> are used in single-threaded contexts. Another is weak_ptr adding a lot >> of complexity to the implementation, IntrusiveRefCntPtr doesn't >> support weak referenc...

...aw pointers and references aren't scary -- > they're just fine. There's no contention there - if the pointer is non-owning, there's no smart pointer to use. Indeed using a smart pointer for a non-owning pointer would actually break the code by causing double deletes, etc. Well, shared_ptr notwithstanding - but, yes, choosing between unique_ptr + non-owning pointers and shared_ptr can sometimes be non-obvious, but I'm hopeful we generally agree that if there is a dominating owner they can be given exclusive ownership through a unique_ptr and everyone else can use raw pointers. &...

...a FAQ, please let me know... So this is my idea at this point: The context is a C++ like language with an aggregate type that is always reference counted. The typesystem differentiate between pointers to objects that is shared between threads and those that does not. I also want a pass that turn shared_ptr to nonshared_ptr if it can be proven. So what I want to do is to wrap up all the "events" that are relevant as intrinsics and run some simplification passes, then use the pointer capture/escape analysis that LLVM has to turn shared_ptrs to nonshared_ptrs and to elide nonatomic/atomic acq...

...tion would look like: { smart_ptr<T> p(new T); if (condition1) { f(p.StopOwn()); // takes ownership of p } p->SomeMethod(); if (condition2) { return nullptr; // } g(p.Get()); // don't take ownership of p return p.StopOwn(); } Neither unique_ptr nor shared_ptr can be used in the place of smart_ptr as unique_ptr sets the raw pointer to nullptr after release() (StopOwn() in the example above) whereas shared_ptr is unable to release. Attached is a scratch that illustrates how the minimal API/implementation of a desired smart pointer sufficient for refac...

There seems to be some uncertainty about the use of smart pointers (previously OwningPtr, now std::unique_ptr and std::shared_ptr predominantly) in the LLVM project as a whole, so here's a thread to discuss/clarify/etc the project preferences/direction with regard to smart pointer usage. For some context, see discussions in LLVM r212403 and Clang r213307. The basic question here seems to be whether smart pointer ownersh...

...> > > } > > > > g(p.Get()); // don't take ownership of p > > return p.StopOwn(); > > } > > What does it mean to stop owning the pointer twice? Doesn't this leak p > in the case where condition1 was false? > > > Neither unique_ptr nor shared_ptr can be used in the place of smart_ptr > as > > unique_ptr sets the raw pointer to nullptr after release() (StopOwn() in > the > > example above) whereas shared_ptr is unable to release. > > I don't understand why shared_ptr wouldn't suffice for the example > above...

...DiagnosticPrinter::OwnsOutputStream, for example either owns its own newly allocated stream or uses std::cout (or cerr, or something) - it can never share the ownership of that stream, so it really must be "own something or own nothing". (I suppose we could use a custom no-op deleter on a shared_ptr in that case, though) But I'm open to the idea that that's the simpler/better answer than introducing a new construct - just a bit hesitant. Thanks for bringing it up as a possibility. - David > > On Nov 13, 2014, at 9:42 AM, David Blaikie <dblaikie at gmail.com> wrote: >...

...first, so it goes out of scope last), but makes the context ownership > redundant: the modules are always freed first via their unique_ptr's. > > I don't think it makes sense for LLVMContext to own Modules. I think that > Modules should share ownership of their LLVMContext via a shared_ptr. > > Thoughts? > > Cheers, > Lang. > > On Sat, Sep 15, 2018 at 4:14 PM Lang Hames <lhames at gmail.com> wrote: > >> Hi All, >> >> ORC's new concurrent compilation model generates some interesting >> lifetime and thread safety questions aroun...

hi, when using the execution engine (no matter, if JIT or Interpreter) i get the following assertion as soon as i use boost::shared_ptr: /build/buildd/llvm-2.5/lib/Target/X86/X86CodeEmitter.cpp:522: void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && "JIT does not support inline asm!\n"' failed. how can i find out which instruction is...

...nst std::unique_ptr &' or anything.) > > Jordan > > > On Jul 17, 2014, at 16:21 , David Blaikie <dblaikie at gmail.com> wrote: > > > There seems to be some uncertainty about the use of smart pointers > > (previously OwningPtr, now std::unique_ptr and std::shared_ptr > > predominantly) in the LLVM project as a whole, so here's a thread to > > discuss/clarify/etc the project preferences/direction with regard to > > smart pointer usage. > > > > For some context, see discussions in LLVM r212403 and Clang r213307. > > > &g...

...ea at this point: >> >> The context is a C++ like language with an aggregate type that is >> always reference counted. The typesystem differentiate between >> pointers to objects that is shared between threads and those that >> does not. I also want a pass that turn shared_ptr to nonshared_ptr if >> it can be proven. >> >> So what I want to do is to wrap up all the "events" that are relevant >> as intrinsics and run some simplification passes, then use the >> pointer capture/escape analysis that LLVM has to turn shared_ptrs to...

...re/release (indeed I wouldn't mind more implicit acquisition from an always-owning pointer (unique_ptr) to a sometimes-owning pointer (whatever we end up calling it), though release is always going to be explicit I suspect). > and we've seen around 20% performance > improvement over shared_ptr due to savings on acquire/release > semantics. The existing use cases I'm interested in aren't using shared_ptr and wouldn't be ideally migrated to it (in some cases the existing ownership might be on the stack (so it can't be shared) or several layers up the call stack through...

...e know... > > So this is my idea at this point: > > The context is a C++ like language with an aggregate type that is always reference counted. The typesystem differentiate between pointers to objects that is shared between threads and those that does not. I also want a pass that turn shared_ptr to nonshared_ptr if it can be proven. > > So what I want to do is to wrap up all the "events" that are relevant as intrinsics and run some simplification passes, then use the pointer capture/escape analysis that LLVM has to turn shared_ptrs to nonshared_ptrs and to elide nonatomic/...