similar to: [LLVMdev] Use of Smart Pointers in LLVM Projects

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 >

No objections here. I'd be glad to see this go in. :) - Lang. On Fri, Jul 18, 2014 at 4:30 PM, Eric Christopher <echristo at gmail.com> wrote: > Sounds like we've got sufficient amount of momentum here for Dave to > go ahead and recommit. Any last objections? > > -eric > > On Fri, Jul 18, 2014 at 1:35 PM, Eli Bendersky <eliben at google.com> wrote: >

Hi Alp, A clear place that smart pointers *shouldn't* be used are 'create' > functions. > > There's already a strong convention in the thousands of 'create' functions > across the codebase and they have the clear, well-defined behaviour of > returning a new pointer. > > We all know what to expect from these functions, much like new/delete in > C++

On Thu, Jul 17, 2014 at 4:45 PM, Alp Toker <alp at nuanti.com> wrote: > > On 18/07/2014 02:21, David Blaikie wrote: >> >> Are people OK with/prefer the use of owning smart pointers in APIs? > > > I think smart pointers are great to use for storage, or as struct members > where there's actually a clear need for ownership. Just by virtue of getting > rid of

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

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

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

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

Agreed, the existing ownership seems sub-optimal. I wouldn't say broken, but subtle at least - looks like you get the choice to either manage the ownership of the Module object yourself, or let the context handle it (eg: currently it'd be valid to just do "{ LLVMContext C; new Module(C); new Module(C); }" - Modules end up owned by the context and cleaned up there). Might be hard

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

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

My code to create an ExecutionEngine is segfaulting: std::string errStr; llvm::ExecutionEngine * ee = llvm::EngineBuilder( unique_ptr<llvm::Module>(module) ) .setErrorStr( &errStr ) //line 1618 .setEngineKind( llvm::EngineKind::JIT ) Where module is a `llvm::Module*`. This is code I'm migrating from 3.3 to 3.8. Since the deletion error is happening during

Hi to everyone, while working with the machine scheduler for a personal project, I came up with the necessity of inserting a backup boundary in the MachineSchedulerStrategy -- specifically, the PostGenericScheduler -- to hold a copy the scheduler's state, in order to implement a really trivial (and really inefficient) backtracking mechanism. This approach leads to a subtle "segmentation

Hi All, ORC's new concurrent compilation model generates some interesting lifetime and thread safety questions around LLVMContext: We need multiple LLVMContexts (one per module in the simplest case, but at least one per thread), and the lifetime of each context depends on the execution path of the JIT'd code. We would like to deallocate contexts once all modules associated with them have

Hi Kostya, Evgenii, and David, Recently I've been making some incremental changes to the XRay runtime implementation in compiler-rt to reduce the reliance on the C++ standard library components that might have external linkage dependencies. This involves not using containers from the STL and not using non-trivially destructible C++11 thread_local objects. I was wondering whether the

+Lang for JIT things. On Sun, Jul 24, 2016 at 8:50 AM koffie drinker via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > I'm building a runtime that can jit and execute code. I've followed the > kaleidoscope tutorial and had a couple of questions. Basically I have a > pre-compiler that compiles the code to cache objects. These cached objects > are

Hi Koffie, I'd highly recommend switching to ORC from MCJIT. It is much more flexible when it comes to memory-management. 1. I took the approach of 1 execution engine with multiple modules (I'm not > removing modules once they have been added). During profiling, I noticed > that the memory usage is high with a lot of code. How can I reduce the > memory usage? Is one execution

On Wed, Oct 1, 2014 at 3:14 PM, Anton Yartsev <anton.yartsev at gmail.com> wrote: > Ping! > > Suggested is a wrapper over a raw pointer that is intended for freeing > wrapped memory at the end of wrappers lifetime if ownership of a raw > pointer was not taken away during the lifetime of the wrapper. > The main difference from unique_ptr is an ability to access the wrapped

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