similar to: [LLVMdev] question about LLVMContext

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

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

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

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

I want to create an add instruction that takes two constant operands at the LLVM IR level. I use the IRBuilder class, but nothing happens. Here is part of the runOnFunction() method of my function pass: ... LLVMContext &Context = F.getContext(); IRBuilder<> builder(&Instruction); Value *Lef = ConstantInt::get(Type::getInt32Ty(Context), 4); Value *Rig =

On Wed, Jan 14, 2015 at 9:05 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015 Jan 14, at 07:58, Duncan P. N. Exon Smith <dexonsmith at apple.com> > wrote: > > > >> > >> On 2015 Jan 13, at 23:59, David Blaikie <dblaikie at gmail.com> wrote: > >> > >> > >> > >> On Tue, Jan 13, 2015

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

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

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

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

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"*) > };

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.

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

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 all, I'm rather new to LLVM and intend to dive into partial evaluation with LLVM. I tried to run the example from http://llvm.org/devmtg/2008-08-23/llvm_partial.pdf, which worked after some adaptations, which were necessary, because LLVM evolved since the slides were made. However, I also tried to get the same example running as an optimization pass following the instructions in

As an update, it is a memory problem which I don't know how to fix. I tried to skip the problematic piece of code when in the case when the loop hangs. So I did something like : if( instr ) { LLVMContext& C = instr->getContext(); Value* values[cnt]; errs()<<"\ngy: \n"; if(!(desters==7)){ // this

Hi, I don't know much about this issue, but this malloc error won't be solved by a change to delete[] or free. In fact, if you use the incorrect one for simple types, you may not notice it. The error you have seems to me like a memory corruption because you went out of bound and corrupted the memory somewhere, Valgrind may help you figure out what is going on. Cheers, Matthieu

Some of the IR constructors require an LLVMContext parameter. Should this just come from say Module M.getContext() ??? Tia. Reed

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

I am trying to create such module with API (it's equivalent to c++: const char* ss[] = {"s1","s2"};): @ss = global [2 x i8*] [i8* getelementptr inbounds ([3 x i8]* @.str1, i32 0, i32 0), i8* getelementptr inbounds ([3 x i8]* @.str2, i32 0, i32 0)] ; <[2 x i8*]*> [#uses=0] @.str1 = private constant [3 x i8] c"s1\00", align 1 ; <[3 x i8]*> [#uses=1]