similar to: [LLVMdev] LLVM IR

Hi all, I am new to LLVM (even the field of compiler) and currently I am engaged in the work of adapting LLVM IR to M5 simulator to observe the enhancement of the novel architecture we design. Simply speaking if you know little about M5, my aim is to know how LLVM IR is interpreted and encoded, then try to implement it in the framework of M5. I have read the LLVM documents, yet I still have some

Hello Duncan Sands, >From your reply, what I can understand is that there is no any new OPENMP specific instructions introduced into LLVM IR as a part of DragonEgg project since GCC has already done the job of lowering OpenMP directives into GOMP runtime library calls at LOW GIMPLE IR level. Now, it throws up following questions. 1. Am I correct that DragoEgg should logically supports

I tried to compile this snippet of C++ code: void FuncTest() {     int* a = new int;     int* b = new int[2]; } using: clang test.cpp -S -emit-llvm -o - > test.llvm and obtained this: define void @_Z8FuncTestv() { entry:   %a = alloca i32*, align 4   %b = alloca i32*, align 4   %call = call noalias i8* @_Znwj(i32 4)   %0 = bitcast i8* %call to i32*   store i32* %0, i32** %a, align 4  

Moving this month old RFC to llvmdev. Not sure why I sent this to cfe-dev in the first place... --- Based on code review discussion from John, he thinks filter expressions should be emitted into the body of the function with the try, rather than being outlined by the frontend. Instead of having the frontend create filter functions, we would use labels in place of typeinfo. The IR would look

Hi, If the special handling in the meg2reg pass is to look for lifetime intrinsics, shouldn't it cast to <IntrisicInst> and then use getInstrinsicID to check for lifetime_start and lifetime_end ? The thing that I don't understand is the following piece of code, which finds all the users and cast it to <Instruction> then eraseFromParent(). How can this guarantee that it only

I'm having an issue where SROA will throw away no-alias information on some loads after inlining, because the loads are derived from a store to an alloca which can be removed after inlining. The pointers that were originally stored into the alloca do *not *have any aliasing information - the only context that allowed me to assert aliasing was that the inlined-function guaranteed it to be so.

As others have mentioned, C++ mangles names (i.e., it changes the name of a symbol into a string that contains both the name, scope, and type of the variable or function), so if you know what the mangled name is of your allocator, you can recognize it. Additionally, I believe that functions with return values marked with the noalias attribute are, essentially, memory allocators because the

Hi Duncan, A DragonEgg/GCC-related question: do you know where these strange FRAME tokens originate from (e.g. %struct.FRAME.matmul)? Compiling simple Fortran code with DragonEgg: > cat matmul.f90 subroutine matmul(nx, ny, nz) implicit none integer :: nx, ny, nz real, dimension(nx, ny) :: A real, dimension(ny, nz) :: B real, dimension(nx, nz) :: C integer :: i, j, k real,

Well, after many months of effort, my LLVM-based garbage collector is finally passing its unit tests. This represents a significant milestone for me in the development of my programming language, Tart. The collector itself is fairly rudimentary - a single-generation, copying collector. It does not yet support multi-threaded programs, but in practice there's no serious obstacle to supporting

Hi all, I'm currently running into some problems with instcombine changing the type of alloca instructions. In particular, the PromoteCastOfAllocation looks at any allocation instruction that is used by a bitast. It does a few checks, but basically tries to change the type of the alloca instruction to the type pointed to by the bitcasted type. The current heuristic for determining if this is

Hi, I haven't been able to reproduce this problem on a smaller test and the original source code is from another virtual machine's IR. What I found out was that 42 << 7 is actually DPSoRegImmFrm, defined in ARMInstrFormats.td. This format is not dealt with in the ARMCodeEmitter.cpp and that's the problem I'm facing. The triple I'm using is

Hi Guillermo, I’m unable to reproduce the error you’re seeing with your bitcode input. “llc –mtriple armv7a-unknown-linux-gnueabi –O3” succeeds. What are you using to reproduce, and what version? Cheers, James From: Guillermo Perez [mailto:gaperez64 at gmail.com] Sent: 20 February 2012 11:32 To: James Molloy; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] ARM opcode format Hi, I haven't

Hello, I have come across an unusual behavior where instruction domination rule is violated "Instruction does not dominate all its uses." It concerns with StackColoring pass present at llvm/lib/CodeGen/StackColoring.cpp. I am reaching out to the LLVM community to help me understand the cause of this issue and the working of the pass. The IR produced at the end of the pass seems to be

Hi, I have the following code, the lines preceded by `>` being added at runtime (the snipped was also printed at runtime) define i32 @myfunc(i32 %pi) { entry: %pi_addr = alloca i32 ; <i32*> [#uses=3] %retval = alloca i32 ; <i32*> [#uses=2] %tmp = alloca i32 ; <i32*> [#uses=2] > %ptr32 = alloca i32

Hi, I'm using LLVM to convert expressions to native assembly, the problem is when LLVM compiles this code: define void @fn_0000000000000000(i8*, i8*, i8*) { bb: %res = alloca i32 %3 = load i32* %res %4 = bitcast i8* %0 to i32* %5 = load i32* %4 %6 = bitcast i8* %0 to i32* %7 = load i32* %6 %8 = xor i32 %5, %7 store volatile i32 %8, i32* %res %9 = load i32* %res %10 = icmp

Hi, guys! I write a virtual machine which uses LLVM as back-end code generator. The following function code causes strange "UNREACHABLE executed!" error: define void @p1(%1*) { %2 = call i8* @llvm.stacksave() %3 = alloca %0 %4 = getelementptr %0* %3, i64 1 %5 = ptrtoint %0* %3 to i64 %6 = ptrtoint %0* %4 to i64 %7 = sub i64 %6, %5 %8 = bitcast %0* %3 to i8* call void

Sorry, %3 instead of %4. 2011/9/14 Rafael Baldiati Parizi <parizi.computacao at gmail.com> > Hello, > I created a new block for execution to continue, but I got the case in > which a statement defined in a block is used in another, not dominate all > uses. > For example: > > entry: > %n_addr = alloca i32, align 4 > %retval = alloca i32 > %"alloca

> How is c's const keyword translated when compiling c into > llvm bytecode. It isn't. You can verify this quite simply with the following test program: void a(const void *p) { } void b(void *p) { } $ clang --emit-llvm test.c ; ModuleID = 'foo' define void @a(i8* %p) { entry: %p.addr = alloca i8* ; <i8**> [#uses=1] %allocapt = bitcast

I'm trying to track down the problem with the assertion failure in SelectionDAGBuilder.cpp. This is the code: *case* *Intrinsic*::gcroot: *if* (GFI) { *const* Value *Alloca = I.getArgOperand(0); *const* Constant *TypeMap = cast<Constant>(I.getArgOperand(1)); * FrameIndexSDNode *FI = cast<FrameIndexSDNode>(getValue(Alloca).getNode());*

Hi all, I've been looking at some LLVM assembly produced by llvm-gcc lately and I've noticed a recurring statement of which I'm not sure its purpose. For example, the following C program: int main(void) { void (*f)(void) = (0x21332); f(); } When compiled with "llvm-gcc -emit-llvm -S" will produce the following code (irrelevant parts removed): define i32 @main()