similar to: [LLVMdev] Adding variants of some instructions

Hi, I am using DataStructureAA.cpp (poolalloc project) for alias analysis purposes and have noticed an error in getModRefInfo(). The situation is that Mod/Ref info is called with a CallSite and GlobalVariable argument, where the global is passed as an argument to the call. Furthermore, the callee function does *nothing* with this global but to pass it on to another callee function. In

Hi, I am using the scc_iterator class in my code on a CallGraph, where some functions are not called from within the module. It seems that scc_iterator does not list all SCCs if the graph is not connected; only those nodes connected to the node pointed to by GraphTraits<...>::getEntryNode() are returned. Can someone verify this behavior? Any tips on how I should go about extending the

Chris Lattner wrote: > On Sep 3, 2009, at 4:15 AM, Hans Vandierendonck wrote: > Hi, >> >> I am using the scc_iterator class in my code on a CallGraph, where some >> functions are not called from within the module. It seems that >> scc_iterator does not list all SCCs if the graph is not connected; only >> those nodes connected to the node pointed to by >>

On Sep 3, 2009, at 4:15 AM, Hans Vandierendonck wrote: Hi, > > I am using the scc_iterator class in my code on a CallGraph, where > some > functions are not called from within the module. It seems that > scc_iterator does not list all SCCs if the graph is not connected; > only > those nodes connected to the node pointed to by > GraphTraits<...>::getEntryNode() are

Just a note: I just checked in a change that corrects some very non-intuitive behavior of the AllocaInst & MallocInst classes. Before, the constructor would take a Type which would specify the return type of the instruction, instead of the operand type. Now it takes the operand type directly. More concretely: LLVM Code: X = alloca int ; int* Y = malloc int * ; int** Old C++

On Sat, 23 Oct 2004, Misha Brukman wrote: > > A possible view of intrinsics could be "operations that don't depend > > on the target architecture, but instead on the language runtime". But > > then wouldn't malloc/free be intrinsics? > > Good question. Due to the amount of pointer/data analysis in LLVM, it > is often necessary to consider memory

Hi all, Would it be correct to say that the only instructions in LLVM IR that modify/access memory potentially are the following: (1) LoadInst : Ref (2) StoreInst : Mod (3) VAArgInst : Ref (?) (4) AllocaInst : Mod (5) MallocInst : Mod (6) FreeInst : Mod (7) CallInst : Mod/Ref ? Also, my earlier impression was that the GEP instruction only computes the effective address and does not

Prakash Prabhu wrote: > Hi all, > > Would it be correct to say that the only instructions in LLVM IR that > modify/access memory potentially are the following: > I believe that every instruction has a mayWriteToMemory()/mayReadToMemory() method that you can use to determine this information. See http://llvm.org/doxygen/classllvm_1_1Instruction.html (the LLVM doxygen info on

On Fri, Oct 22, 2004 at 03:18:00PM +0200, Marc Ordinas i Llopis wrote: > I'm currently looking at LLVM as a possible back-end to a dynamic > programming system (in the tradition of Smalltalk) we are developing. Neat! > I have read most of the llvmdev archives, and I'm aware that some > things are 'planned' but not implemented yet. We are willing to > contribute

On Jan 12, 2009, at 8:24 AM, Dan Gohman wrote: > > On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote: > >>>> There is no good reason for malloc to be an instruction anymore. >>>> I'd >>>> be very happy if it got removed. Even if we keep it, malloc/alloca >>>> should be extended to optionally take 64-bit sizes. >>> >>>

Hey Everyone, I know that LLVM subscribes to the notion of "progress over backwards compatibility." And in that spirit, maybe someone could help me better understand the motivation behind removing the MallocInst? Is there a design doc anywhere? From a pragmatic sense, the IRBuilder's createMalloc, which was returning a MallocInst, was doing a lot of messy work for

On 7/23/07, abhi232 at cc.gatech.edu <abhi232 at cc.gatech.edu> wrote: > Hi Bill, > Thanks a lot for your response.But my problem still remains.The thing is i > am having a data type std::vector<Value*> as i am checking for the > variables in Store Instructions and Malloc Instructions.For store the case > is straightforward as discussed earlier.I want the same Value*

Hi Misha, Thanks for your answer I was doing this: ======================== BasicBlock *BBlock = new BasicBlock("entry", MyFunc); ... Value *Zero = ConstantSInt::get(Type::IntTy, 0); Value *UZero = ConstantUInt::get(Type::UIntTy, 0); MallocInst* mi = new MallocInst( STyStru ); mi->setName("tmp.0"); BBlock->getInstList().push_back( mi );

Hello, have a short look at the following simple c-prog: #include <stdlib.h> int main(int argc, char* argv[]) { void* buf = malloc(10 * sizeof(char*)); /* do sth with buf, so that it is not "optimized away" */ return 0; } When you compile this using a plain llvm-gcc, the call to libc-malloc is left inside.But compiling it with -O2 alters the call to llvm::MallocInst. Now

On Jan 11, 2009, at 11:22 AM, Chris Lattner wrote: >>> There is no good reason for malloc to be an instruction anymore. >>> I'd >>> be very happy if it got removed. Even if we keep it, malloc/alloca >>> should be extended to optionally take 64-bit sizes. >> >> I'm curious. Do we want to keep the free instruction? > > No,

Thanks very much. I only have one more question, (hopefully), which is, is there a better way of finding the direction of stack growth other than: static bool StackCmp(void *ptr) { volatile int a; return (void *)&a > ptr; } bool FindStackDirection() { volatile int a; return StackCmp((void *)&a); } Preferably one which isn't destroyed by optimization. Thanks again,

On Oct 16, 2009, at 4:43 AM, Daniel Waterworth wrote: > Never mind, I used ExecutionEngine's InstallLazyFunctionCreator and > DisableSymbolSearching to cause malloc and free calls to be handled > by my logging functions. Sorry for the unnecessary list mail. No problem, this is a better way to go. The MallocInst and FreeInst instructions are about to be removed from LLVM IR.

Hi Abhinav, > If i have an IR instruction of the form > %tmp10 = call sbyte* %malloc( uint 4 ) ; <sbyte*> [#uses=1] > %tmp10 = cast sbyte* %tmp10 to int* ; <int*> [#uses=1] > store int* %tmp10, int** %t > > which is nothin but a malloc call how can i get %tmp into maybe a variable > set. > > If i have a store instruction then it is

Hi, I'm currently implementing some optimization passes for LLVM and I came across a problem. I'm new to LLVM so if this question has been asked before please kindly tell me where can I find the answer. There are 2 types of AllocationInst - Alloca and Malloc. But most of the time from the compiled byte code I can only find the Alloca statement (actually I never come across a

On Sun, Oct 24, 2004 at 01:17:19AM -0500, Chris Lattner wrote: > The one advantage that mallocinst has over using an intrnisic is that > instructions can have different return values in various parts of the > program (e.g., you can write 'malloc int' instead of > '(int*)malloc(4)'). OK, then you could say that the *real* advantage of the malloc/alloca instructions is