search for: llvmcontexts

Hello, I'm trying to develop a way to reliably clean the LLVMContext in order to make it possible to use it multiple times. LLVMContext itself is an almost empty object delegating almost all its content to LLVMContextImpl. This makes it very clean ideally, because clearing the LLVMContext would be as easy as deleting the LLVMContextImpl and creating a new one. The problem is that for some

Hi, I'm Ryo Ota. I have two questions about `llvm::LLVMContext`. Q1) What is the difference between the following (A)`my_context` and (B)`global_context`? Do I have to create a LLVMContext by myself? Or use `getGlobalContext()`? Could you tell me what situation needs a LLVMContext which is created by myself such as (A)? (A) { llvm::LLVMContext my_context; // codes using only my_context (get

...PM Lang Hames <lhames at gmail.com> wrote: >>> >>>> 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 been compiled,...

...gt; 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 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 been compiled, but there is no safe or...

Hello, the need here is to have a single LLVMContext used for multiple compilations. You make a good point about that by the way. If there are outstanding users cleaning the context under their seats might still pose a risk to them, and in that case deleting + newing a new LLVMContextImpl might actually not be very different. Marcello 2014-06-24 17:14 GMT+01:00 David Blaikie <dblaikie at

Something like, keeping the compiler alive for a many compilation sessions, using the same LLVMContext, but without the problem of accumulating data in the LLVMContext that would slowly fill up the memory. This as much I can enter into details that I can :/ Probably this is also a quite common use case scenario too. Marcello 2014-06-24 18:52 GMT+01:00 Eric Christopher <echristo at

...on't rely on pImpl remaining always the same pointer. > > This makes it more difficult to clear LLVMContext. I can't comment on your solution. But again the open source OpenGL driver stack is suffering from problems connected to LLVMContext. So our observation is, if we use several LLVMContexts within the program execution lifetime, LLVM accumulates memory that is only freed on destruction of the managed singletons. It turns out that in SDNode::getValueTypeList(EVT) the non simple value types are cached and keyed by a llvm::Type value which in the end refers to a LLVMContext reference val...

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 been compiled, but there is no safe or easy way to check that con...

Notice of a major upcoming API change: The static methods for constructing types and constants will be going away in the future. Instead, the global uniquing tables that lurk behind these APIs will be privatized within LLVMContext instances. What this means for you: Your client application will need to create an LLVMContext in main(), and pass it into a few APIs (the constructor for

On Feb 13, 2013, at 17:26 , Lang Hames <lhames at gmail.com> wrote: > LLVMContext was designed to support multithreading by holding the compilation context for each thread in a separate LLVMContext. If you're building modules in parallel you definitely need one LLVMContext per thread. > > If you're talking about compiling multiple modules sequentially with a single context

Hi devs: I'm trying to do something quite simple, but it seems I need to provide an LLVMContext& to do it. I'm not sure what the 'proper' LLVMContext would be in my situation. I'm writing an analysis that is a FunctionPass. At some point in the pass, I am given a Value * representing an N-bit integer. My goal is to contruct two ConstantInt instances, for comparison

Hi, LLVMContext was designed to support multithreading by holding the compilation context for each thread in a separate LLVMContext. If you're building modules in parallel you definitely need one LLVMContext per thread. If you're talking about compiling multiple modules sequentially with a single context I believe that should work, though I don't know how well tested it is. I think

When building multiple modules should I be using multiple LLVMContext's or just one of them shared between the modules? I'm a little bit uncertain in regards to how the types work. The IR type checking appears to check exact ptrs for equality so how would multiple contexts actually work? Or is the type checking limited to within a given module? -- edA-qa mort-ora-y -- -- -- -- -- -- --

To ease this transition, I have added a getGlobalContext() API. If you're only ever planning to use LLVM on a single thread, it will be completely safe to simply pass this value to every API that takes an LLVMContext. --Owen On Jun 30, 2009, at 3:38 PM, Owen Anderson wrote: > Notice of a major upcoming API change: The static methods for > constructing types and constants will

So, as you all probably noticed, the APIs for creating constants have been moved (or in a specific cases, are about to be moved) from static methods on Constant to instance methods on LLVMContext. However, as was recently pointed out on llvm-commits and on IRC, this is no longer strictly necessary. Because types have contexts, all of the constant subclasses could be friended to

I get a crash when I try to link multiple modules registered in their individual contexts. Documentation for Linker::LinkModules doesn't mention anything about contexts, and the first link succeeds. But the second link crashes. Is this not the right way to merge such modules? If not, then what is the right way? In any case, documentation for Linker::LinkModules should say if contexts are

That's awesome, thanks very much for working on this Owen. So if I understand correctly, there can be as many LLVMContext instances as we want? Or one module only has a single LLVMContext? A similar question is: can I now delete constants created, after JIT-compiling a function's IR? I know we can already delete the body of the function, but not the constants the body needs. So can we

Owen Anderson wrote: > On Jul 15, 2009, at 7:44 AM, John Criswell wrote: > >> 1) If technically possible, add the new API first, get it working, >> email >> llvmdev describing the old and new APIs, provide some lead time for >> people to change over, and then remove the old APIs. This makes it >> easier to plan when I fix problems due to LLVM API changes

On Jul 15, 2009, at 7:44 AM, John Criswell wrote: > 1) If technically possible, add the new API first, get it working, > email > llvmdev describing the old and new APIs, provide some lead time for > people to change over, and then remove the old APIs. This makes it > easier to plan when I fix problems due to LLVM API changes and when I > can work on our own bugs. :) The

Owen Anderson wrote: > > On Jul 15, 2009, at 9:53 AM, John Criswell wrote: > >> Owen Anderson wrote: >>> On Jul 15, 2009, at 7:44 AM, John Criswell wrote: >>> >>>> 1) If technically possible, add the new API first, get it working, >>>> email >>>> llvmdev describing the old and new APIs, provide some lead time for