search for: int64ti

I have something like this on my code :- vector<Value*> args3; args3.push_back(instr->getOperand(0)); //where 'instr' is store instruction Now when I check the Type of instr->getOperand(0). It varies to i32 and i64, depending on the operand(0) of instruction. Due to which my vector<Value*> has different Type of Value*. How can I convert i32 to i64 type before pushing

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

I'm implementing c style "sizeof()", and I did as http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt illuarstrated, and it works find, here's an example of my implementation: auto *p = builder.CreateGEP(structTy, llvm::ConstantPointerNull::get(pointerTy), constint1); auto *size =

Hello, I'm trying to compile vmkit on a x86_64 linux box with gcc-4.1.2, but I'm running into troubles because of various problems with casts between pointers and integers. Is there anybody who succeeded in this task? Az I see, some of the problems can be fixed with an appropriate typedef/macro declaration, but in VMCore/JavaObject.cpp some lowlevel bitmanipulation is used, to mark

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 Zsombor, Thanks for the patch! Unfortunately I can't apply it because the llvm API has moved from BinaryOperator::create to BinaryOperator::Create. Are you using svn head? Now on the x86_64 part. There has been very little work on porting vmkit on x86_64. If you're having compilation problems, I suppose it's in the garbage collector directory (GCMmap2). If you could make the

Hi all, I couldn't find any reasonable way to create the IntegerType that would match, say, intptr_t, that is the native word size of the machine I'm building on. More accurately defined, when compiling on a 64 bit Mac OS machine I want it to be Int64Ty, but if for example I'm using the "-arch i386" command line option on that machine during compilation, I want it to be

Dear all, I'm writing an LLVM pass, and I want to insert a call instruction that takes a function pointer as a parameter. The effect would be the same as following: atexit(foo); Where foo is a function I insert with M.getOrInsertFunction(), which in LLVM is a Function class. I searched for a while and did not come up with a satisfying answer. Should I create a Value class of pointer type,

I think, we must move function arguments lowering from frontend to LLVM core. This lowering is generating machine dependent bytecode. See http://llvm.org/bugs/show_bug.cgi?id=1230 Lauro 2007/2/26, Chris Lattner <sabre at nondot.org>: > On Mon, 26 Feb 2007, Lauro Ramos Venancio wrote: > > The problem is: llvm-gcc generates the same bytecode for both functions: > > > >

Hi, Based on LLVM lang spec (http://llvm.org/docs/LangRef.html#i_bitcast<http://www.google.com/url?sa=D&q=http://llvm.org/docs/LangRef.html%23i_bitcast&usg=AFQjCNFsBtV4Cr8zpL5UpgoIASRDFvcdSw>) notes I have understood ,that bitcast of vectors to vectors is OK,only if provided the vectors are of the same size.Is it possible to convert a vectors from different size? For example a

On Mon, 26 Feb 2007, Lauro Ramos Venancio wrote: > The problem is: llvm-gcc generates the same bytecode for both functions: > > declare void @f(i32, i64) > declare void @g(i32, i64) > > I can't differ an i64 argument from a struct argument. Oops. You can fix this by changing llvm-gcc: gcc/llvm-abi.h Grep for instances of Int64Ty there. I can help answer any q's you

Hello, I am writing a JIT compiler for a subset of the Matlab language and as a part of my implementation, I would like to be able to pass a constant pointer to a native function I'm calling. Right now, this is what I do: llvm::Constant* constInt = llvm::ConstantInt::get(llvm::Type::Int64Ty, (int64)thePointer); llvm::Value* constPtr = llvm::ConstantExpr::getIntToPtr(constInt,

The ARM EABI (AAPCS) defines: - i64 values are 8-bytes aligned - "The alignment of an aggregate shall be the alignment of its most-aligned component." So, struct ss { int x; int y; }; void f(int a, struct ss b); r0 <- a r1-r2 <- b void g(int a, long long b); r0 <- a r2-r3 <- b The problem is: llvm-gcc generates the same bytecode for both functions: declare void

On 2009-03-08, at 12:46, Nyx wrote: > I am writing a JIT compiler for a subset of the Matlab language and > as a > part of my implementation, I would like to be able to pass a constant > pointer to a native function I'm calling. > > Right now, this is what I do: > > llvm::Constant* constInt = llvm::ConstantInt::get(llvm::Type::Int64Ty, > (int64)thePointer); >

> Is it possible to convert a vectors from different size? For example > a vector of 3 elements Int16Ty type to vector having one element of > 64 bit Int64Ty ? Not with a bitcast. You'd probably use a shuffle followed by a bitcast for that: %temp = shufflevector <3 x i16> %incoming, <3 x i16> undef, <4 x i32> <i32 0, i32 1, i32 2, i32 undef> %out = bitcast

Hello, is it correct, that the "llvm.ctpop" Hamming weight intrinsic is currently (LLVM 2.2) implemented in Line 254 in lib/CodeGen/IntrinsicLowering.cpp /// LowerCTPOP - Emit the code to lower ctpop of V before the specified /// instruction IP. static Value *LowerCTPOP(Value *V, Instruction *IP) { assert(V->getType()->isInteger() && "Can't ctpop a

Hi Gyounghwa Kim, > First of all, thank you very much for your answer. > I tried your sugestion and found out that it is not what I wanted. > What I have to do is call a native C function from inside this > generated function. > Is there any way that we can find and call native C functions not > created by LLVM IR? You can insert a declaration of the function into the IR, then

This is x86_64. I have a problem where an absolute memory load define i32 @foo() { entry: %0 = load i32* inttoptr (i64 12704196 to i32*) ; <i32> [#uses=1] ret i32 %0 } generates incorrect code on LLVM 2.4: 0x7ffff6d54010: mov 0xc1d9c4(%rip),%eax # 0x7ffff79719da 0x7ffff6d54016: retq should be 0x7ffff6d54010: mov 0xc1d9c4, %eax 0x7ffff6d54016: retq

Dear experts, I am learning llvm by reading documents and have a question to ask. The following is the example of code generation that I created. [[a [10.00]] > [3.00]] ; ModuleID = 'ExprF' define i1 @expr(double* %record) { entry: %0 = getelementptr double* %record, i32 0 ; <double*> [#uses=1] %1 = load double* %0 ; <double>

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more