similar to: [LLVMdev] Quick Question...

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,

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. >>> >>>

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 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* variable for malloc inst as well. bcos i cannot have a different set for only instructions. can there be

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

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.

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 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

Hello, I'm writing a virtual machine that functions as a sandbox based on llvm. In order to prevent programs from accessing memory that has not been allocated to them, I want to replace calls to malloc and free with calls to a logged functions that will record the memory that is being allocated to the program. Is it possible to cast/convert a MallocInst or FreeInst to a CallInst? Thanks,

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,

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

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. Is it possible to find out the size and beginning pointer of the current stack frame, from a function operating outside of the virtual machine, but called by a function within it? Thanks, Daniel

The following function produces a segv when the begin() is taken from vmap, the ScalarMap... bool StaticMemAnalysis::isSingleMalloc(DSGraph* theGraph,DSNode* theNode) { int count = 0; std::map<Value*, DSNodeHandle>& vmap = theGraph->getScalarMap(); for (std::map<Value*, DSNodeHandle>::iterator i = vmap.begin(); i != vmap.end(); ++i) { if(i->second.getNode() ==

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

Hi everyone, I noticed that MallocInst and FreeInst have been removed from the LLVM IR as well as the language reference[1]. May I propose that at least some placeholder is left in that document telling the reader that these instructions have been removed. This should be kept in at least until there is one official release that does not support these instructions anymore. The same goes for

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

Hi, I encountered an issue when attempting to create a call to function malloc. I just want to do a simple thing, suppose there is a variable p, if p is a pointer then allocate memory to p. Source code: int *p; p = (int *) malloc(sizeof(*p)); Try to generate LLVM IR for it: Type *tp = p->getType(); AllocaInst* arg_alloc = builder.CreateAlloca(tp);//builder is IRBuilder

Ouch! Didn't see that. So at the risk of irritating those still in the process of baking 2.7, what is the sanction way of doing heap allocation going forward? :-) Garrison On Dec 7, 2009, at 11:18, Chris Lattner wrote: > > On Dec 7, 2009, at 2:13 AM, Florian Merz wrote: > >> Hi everyone, >> >> I noticed that MallocInst and FreeInst have been removed from the

Any plans to make LLVM work with Google's new language, Go? http://www.technewsworld.com/story/Go-Go-Google-Programming-Language-68622.html?wlc=1257974768&wlc=1258041607&wlc=1258047741

Hi, I need to have special variants of some instructions, e.g. a special MallocInst that carries some additional information. Besides having this additional information, I want all of LLVM to recognize this instruction as a regular MallocInst. This special MallocInst need only exist inside LLVM; it need not be written out to bytecode. How to best implement this? This is what I was