search for: llvmcontext

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

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

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

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 to migrate existing users away from this without silently introducing memory leaks... maybe with some significant API breakage - move Module construction to a factory/helper that ret...

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

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 gmail.com&...

Hi, On Tuesday, June 24, 2014 15:18:51 Marcello Maggioni wrote: > 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 LLVMContextImp...

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

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 Module, for instance). You can, in theory, have more than one LLVMContext as long as you never want Modules created under separate co...

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

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

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

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

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 be going away in the future. > Instead, the global uniquing tables that lurk behind these APIs will > be privatized withi...

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 LLVMContext, and then put the work of uniquing by accessing the context off of the type. There are obviou...

...rst 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 or aren't expected to be the same. Yuri ---testcase--- #include "llvm/IR/LLVMContext.h" #include "llvm/IR/Module.h" #include "llvm/Linker/Linker.h" #include "llvm/Support/raw_ostream.h" #include "llvm/IR/DiagnosticPrinter.h" #include <string> #include <iostream> using namespace llvm; using namespace std; int main() { //...

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 do that now? Thanks! Nic...

...level change was already described and discussed on LLVMdev. > First, did you discuss it or announce it? There's a difference. With its high traffic volume, I don't read all llvmdev mails anymore. I pick and choose based on their subject lines. A subject entitled "API Change: LLVMContext" will probably get my attention while "Multi-threading support for LLVM" will not. Second, the only emails I remember on the topic was an email that provided a short description of LLVMContext and some followup emails on questions/commit messages from me. The first message announci...

...> easier to plan when I fix problems due to LLVM API changes and when I > can work on our own bugs. :) The high-level change was already described and discussed on LLVMdev. The summary is that the static factory methods on Constant and Type are going away, and becoming instance methods on LLVMContext. All of the instance methods are already in place (though many just forward to the static implementations for the moment). I'm currently in the process of moving the implementations over, removing the static versions, and updating the LLVM tree for it. For basic constant-fetching API...

...on LLVMdev. >>> >> First, did you discuss it or announce it? There's a difference. >> >> With its high traffic volume, I don't read all llvmdev mails anymore. I >> pick and choose based on their subject lines. A subject entitled "API >> Change: LLVMContext" will probably get my attention while >> "Multi-threading support for LLVM" will not. > > How about a subject line "[LLVMdev] MAJOR API CHANGE: LLVMContext"? Yes, that particular message fits the first criterion: it announces the change in the subject line. I...