search for: getint64ti

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

To create a stack based (local) 64 bit integer in LLVM IR, I used: Value *var = builder.CreateAlloca(Type::getInt64Ty(Ctx)); I wish to pass this variable to a function "void foo(unsigned long)". I created the signature of function foo() as follows: Constant *func = M->getOrInsertFunction("foo", Type::getVoidTy(Ctx),Type::getInt64Ty(Ctx), NULL); To pass the newly created

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

I tried the following: - ConstantInt::get(Type::getInt64Ty(Ctx), APInt(0xFFFFFFFFFFFFFFFF, 64, false)) - ConstantInt::get(Type::getInt64Ty(Ctx), APInt(-1, 64)) I am receiving the following error: Assertion `NumBits <= MAX_INT_BITS && "bitwidth too large" failed -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed...

That seems to work, thanks! The specific code I ended up with to call int64_t print(int64_t) looks like: auto f = builder.CreateIntToPtr( ConstantInt::get(builder.getInt64Ty(), uintptr_t(print)), PointerType::getUnqual(FunctionType::get( builder.getInt64Ty(), {builder.getInt64Ty()}, false))); return builder.CreateCall(f, args); On Mon, Mar

The option we use is to have a custom memory manager, override the getPointerToNamedFunction function, and provide the pointer to the external function at link time. The inttoptr scheme works fairly well, but it does make for some pretty ugly and sometimes hard to analyze IR. I recommend leaving everything symbolic until link time if you can. Philip On 03/28/2016 06:33 PM, Russell Wallace

Right, but when you say link time, the JIT compiler I'm writing works the way openJDK or v8 do, it reads a script, JIT compiles it into memory and runs the code in memory without ever writing anything to disk (an option for ahead of time compilation may come later, but that will be a while down the road), so we might be doing different things? On Tue, Mar 29, 2016 at 2:59 AM, Philip Reames

Hello, This patch fixes bug 4882. Regards -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: pr4882.patch Type: application/octet-stream Size: 6856 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090907/266f900c/attachment.obj>

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

I think our use cases are actually quite similar. Part of generating the in memory executable code is resolving all the symbolic symbols and relocations. The details of this are mostly hidden from you by the MCJIT interface, but it's this step I was referring to as "link time". The way to think of MCJIT: generate object file, incrementally link, run dynamic loader, but do it all

Hi, I am trying to write a simple interpreter. I am trying to generate LLVM IR for assignment operation. The code for the generation part looks like this llvm::Value* codeGenSymTab(llvm::LLVMContext& context) { > printf("\n CodeGen SymTab \n"); > Value *num = ConstantInt::get(Type::getInt64Ty(context), aTable.value, > true); > Value *alloc = new

Hi, I want to access an array in my instrumentation code. For example: GlobalVariable: int *counter; //counter the number of load/store operations in run-time int *counterArray; //record the load/store addresses //increase the counter if a load/store is performed std::vector<Constant *>index(2); index[0] = Constant::getNullvalue(Type:getInt32Ty(Context)); index[1] =

Ah! Okay then, so you are saying something substantive that I think I disagree with, but that could be because there are relevant issues I don't understand. My reasoning is, I've already got a pointer to the function I want the generated code to call, so I just supply that pointer, it looks ugly on a microscopic scale because there are a couple of lines of casts to shepherd it through the

Hi All, we have an issue with our LLVM-based JIT compiler - executing the compiled code corrupts memory (and subsequently crashes) if we alloca more than 4k of variables (more than 511 8-byte ints). The same code works on Windows 7 (32 and 64 bit), Linux, MacOS. We compile LLVM and our program with Microsoft's Visual Studio 2010. Both debug and release builds are affected. The variables

Hello, Calling `replaceUsesOfWith` with a value in a different addrspace does not keep the addrspace of a GEP consistent. Is this known? Is this a bug or expected behaviour? Minimal counterexample link <https://gist.github.com/bollu/152ba5e1c20c03c7fc6d8c7b23ba828f> Reproduced here: #include <iostream> #include "llvm/ADT/APFloat.h" #include

> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] > On Behalf Of Russell Wallace via llvm-dev > Subject: [llvm-dev] JIT compiler and calls to existing functions > In the context of a JIT compiler, what's the recommended way to generate a call to an > existing function, that is, not one that you are generating on-the-fly with LLVM, but > one that's already

于 2011/5/18 14:29, Duncan Sands 写道: > Hi Tan Guangming, > >> I want to access an array in my instrumentation code. For example: >> >> GlobalVariable: >> int *counter; //counter the number of load/store operations in run-time >> int *counterArray; //record the load/store addresses > strictly speaking these are not arrays, they are pointers. Also, you have

Hi Tan Guangming, > I want to access an array in my instrumentation code. For example: > > GlobalVariable: > int *counter; //counter the number of load/store operations in run-time > int *counterArray; //record the load/store addresses strictly speaking these are not arrays, they are pointers. Also, you have written them in some kind of C-style idiom. What are the declarations

For what it's worth we did a similar thing, but overrode RTDyldMemoryManager directly This allowed us to control where the RAM was allocated too (e.g. guarantee it was in the low 4GB so we could use small memory model and avoid the mov rax, xxxxxxx; call rax code generated for x86)*, and also override findSymbol() to have the same behaviour as described in 4). --matt * later issues in not