search for: shared_ptrs

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(new CompilerInstance());

Am 29.08.19 um 12:07 schrieb Jonathan Wakely: > On Thu, 29 Aug 2019 at 10:15, Christian Schneider > <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

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

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

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 by LLVM. Also, it's not clear to me if the

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

...;>> Another option would be to invert the ownership model and say that each >>>> Module shares ownership of its LLVMContext. That way LLVMContexts would be >>>> automatically deallocated when the last module using them is destructed >>>> (providing no other shared_ptrs to the context are held elsewhere). >>>> >>>> There are other possible approaches (e.g. side tables for the mutex and >>>> module count) but before I spent too much time on it I wanted to see >>>> whether anyone else has encountered these issues or ha...

On Wed, Oct 19, 2016 at 9:31 PM, Mehdi Amini via llvm-dev < llvm-dev at 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

...ehaviour of > returning a new pointer. > > We all know what to expect from these functions, much like new/delete in C++ > and malloc/free. They can be easily adopted by std::shared_ptr or > std::unique_ptr as needed, They'd actually only ever need to return std::unique_ptr. std::shared_ptrs can be constructed from xvalue std::unique_ptrs without any overhead: std::unique_ptr<T> create(); std::shared_ptr<T> x = create(); (make_shared has a small allocation (and destruction) benefit that might sometimes be useful to exploit, of course, but you don't benefit from that w...

...nd 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 acquire/release. So basically, the intrinsics will be the type-annotation also. The compilation will then follow this pattern: 1. generate LLVM IR 2. simplification passes 3. pass for turning shared_ptr to nonshared_ptr 4. pass for eliding acquire/re...

Hello everyone, I bring to discussion the necessity/design of a new type of smart pointer. r215176 and r217791 rise the problem, D5443 <http://reviews.llvm.org/D5443> is devoted to the solution. r215176 applies several temporary ugly fixes of memory leaks in TGParser.cpp which would be great to be refactored using smart pointers. D5443 <http://reviews.llvm.org/D5443> demonstrates

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

On Wed, Sep 24, 2014 at 7:50 PM, Justin Bogner <mail at justinbogner.com> wrote: > Anton Yartsev <anton.yartsev at gmail.com> writes: > > Hello everyone, > > > > I bring to discussion the necessity/design of a new type of smart > pointer. > > r215176 and r217791 rise the problem, D5443 is devoted to the solution. > > r215176 applies several

On Thu, Nov 13, 2014 at 10:59 AM, Argyrios Kyrtzidis <akyrtzi at gmail.com> wrote: > Could we consider moving the things you listed to shared pointer semantics > ? It will be a simple and clear model; unless someone justifies that it > will be a performance concern to use shared pointers there I don’t think we > need a new and more complex to reason about smart pointer. >

...; delete Ctx; >> >> Another option would be to invert the ownership model and say that each >> Module shares ownership of its LLVMContext. That way LLVMContexts would be >> automatically deallocated when the last module using them is destructed >> (providing no other shared_ptrs to the context are held elsewhere). >> >> There are other possible approaches (e.g. side tables for the mutex and >> module count) but before I spent too much time on it I wanted to see >> whether anyone else has encountered these issues or has opinions on >> solutions...

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.

On Fri, Jul 18, 2014 at 12:06 PM, Jordan Rose <jordan_rose at apple.com> wrote: > I don't have much to add here besides +1. I think using std::unique_ptr > even for create* functions/methods is the right way to go. +1 smart pointers here are a win in terms of safety and self-documentation. I don't see why create* factories should be treated differently. Eli >

...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 acquire/release. So >> basically, the intrinsics will be the type-annotation also. >> >> The compilation will then follow this pattern: >> 1. generate LLVM IR >> 2. simplification passes >> 3. pass for tu...

On Thu, Sep 25, 2014 at 1:44 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 25 September 2014 06:16, David Blaikie <dblaikie at gmail.com> wrote: > > I can go & dredge up some examples if we want to discuss the particular > > merits & whether each of those cases would be better solved in some other > > way, but it seemed pervasive enough in the

...hat 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 acquire/release. So basically, the intrinsics will be the type-annotation also. > > The compilation will then follow this pattern: > 1. generate LLVM IR > 2. simplification passes > 3. pass for turning shared_ptr to nonshared_ptr >...