similar to: [LLVMdev] API CHANGE: Contexts for Passes

> Hey folks, > > As a number of people have observed, the current mechanism for > providing an LLVMContext to each pass is extremely hackish, and tends > to break down in lots of interesting ways. In light of this, I've > decided to drop the automagical nature of this mechanism. Because > types now hold references to contexts, it is now trivial to get a > context from

> On 2015-Jun-01, at 11:06, Reid Kleckner <rnk at google.com> wrote: > > I'm pretty sure module linking is expected to occur in the same LLVM context. Correct. > IIRC Duncan had some proposal for how ld64 could do something clever with multiple contexts, but I've totally forgotten what it was. This was for LTO (probably unrelated to Yuri's scenario?). 1.

A: When the types are created in different contexts. I've been running into a module validation error related to phi nodes produced by the GVN pass, where the types of the incoming values aren't the same instance of IntegerType i1. I'm not certain I've found the root cause of the problem yet, it's probably due to my handling of LLVMContext & Module life cycles, and this

> On 2015-Jun-02, at 12:37, Yuri <yuri at rawbw.com> wrote: > > On 06/01/2015 11:43, Duncan P. N. Exon Smith wrote: >> You can round-trip to bitcode, reading the module into the >> destination context. The following pseudo-code gives the idea: >> >> bool linkModuleFromDifferentContext(Module &D, const Module &S) { >>

Jeremy Lakeman wrote: > A: When the types are created in different contexts. > > I've been running into a module validation error related to phi nodes > produced by the GVN pass, where the types of the incoming values aren't > the same instance of IntegerType i1. > > I'm not certain I've found the root cause of the problem yet, it's > probably due to my

Hi Jakub, looks good. > + LLVMContext *Context = &SI->getContext(); I guess this could be LLVMContext &Context = SI->getContext(); which means you can use Context rather than *Context below. > - const Type *Ty = Type::getInt64Ty(SI->getContext()); > - MemSetF = Intrinsic::getDeclaration(M, Intrinsic::memset, &Ty, 1); > + const Type *Tys[] =

On Sep 7, 2009, at 5:02 PM, Duncan Sands wrote: > Hi Jakub, looks good. > >> + LLVMContext *Context = &SI->getContext(); > > I guess this could be > LLVMContext &Context = SI->getContext(); > which means you can use Context rather than *Context below. Right, C bad habit ;) Fixed. >> - const Type *Ty = Type::getInt64Ty(SI->getContext());

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

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

I also tried the following, with no compilation errors, but segfault, core dumped: *LLVMContext& C = is->getContext(); Value* values[size]; for(int gy=0;gy<size;gy++){ values[gy]=ConstantInt::getSigned(Type::getInt64Ty(C),array[gy]); } llvm::ArrayRef<Value*> bla = values[size]; is->setMetadata("path",MDNode::get(C,bla));* On Fri, May 3, 2013

Martin Apel wrote: > static LLVMContext context; That's your bug. Here's the situation that contexts help with. Suppose you write a library that uses LLVM under the hood (graphics, let's say), and I write another one that uses LLVM and does audio processing. Someone then decides to write a video game that uses both of our libraries. As long as we each use a separate context,

Hello everyone, I want to pass a set of integers using metadata but I don't know how. I have tried: the integers are in array[] *1. * LLVMContext& C = is->getContext(); Value* values[size]; for(int gy=0;gy<size;gy++){ values[gy]=ConstantInt::getSigned(Type::getInt64Ty(C),array[gy]); } *is->setMetadata("path",MDNode::get(C,values));* failes when setMetadata(),

Hi Alastair, Thank you so much for the information on the tools. Actually, I need to analyze which sections of code are prone to misses and mis predicts, and would have to eventually instrument the code. I was able to instrument and call an external function, but faced an issue while passing an argument to the function. I am following EdgeProfiling.cpp but couldn't figure out the problem.

I think the better solution should be: LLVMContext& C = is->getContext(); Value *values[] = { ConstantInt::getSigned(Type::getInt64Ty(C), *scsr*), MDString::get(C, *"path"*) }; lnstr.setMetadata(*"your_analysis_name"*, MDNode::get(C, values)); So that you can take advantage of the type system of LLVM bitcode, and don't have to cast the integers from/to strings

Hello, I am editing the LowerTypeTests pass in LLVM, and part of my additions include the following 3 lines of code: // newTypeName is a std::string MDString* newMD = MDString::get(M.getContext(), newTypeName); ArrayRef<Metadata*> mdArray {ConstantInt::get(Int64Ty, 0), newMD}; auto* node = MDTuple::get(M.getContext(), mdArray); Thus far, I have been developing on a version of Clang with

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

I agree that the ArrayRef is likely the issue. I've debugged a crash caused by a temporary ArrayRef like that a couple times. Either do what David suggested or use a normal array: Metadata *mdArray[] = {ConstantInt::get(Int64Ty, 0), newMD}; ~Craig On Thu, Apr 30, 2020 at 9:56 AM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Apr 30, 2020 at

Yes, it sounds good. I can try tomorrow. Thank you for your advice ! On Thu, May 2, 2013 at 5:43 PM, Logan Chien <tzuhsiang.chien at gmail.com>wrote: > I think the better solution should be: > > > LLVMContext& C = is->getContext(); > Value *values[] = { > ConstantInt::getSigned(Type::getInt64Ty(C), *scsr*), > MDString::get(C, *"path"*) > };

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 Jan 6, 2010, at 12:45 PM, Talin wrote: > This patch adds a UnionType to DerivedTypes.h. Cool. When proposing an IR extension, it is usually best to start with a LangRef.html patch so that we can discuss the semantics of the extension. Please do write this before you get much farther. I assume that you want unions usable in the same situations as a struct. However, how do "constant