search for: mallocinsts

...e written out to bytecode. How to best implement this? This is what I was thinking: * Not to introduce a new instruction, but to represent special MallocInst as a derived class from MallocInst * Introduce the special MallocInst instructions during a pass that decides to replace some original MallocInsts or some other code by special MallocInst * Apply LLVM analysis and transformations assuming that when new MallocInsts are created, the proper clone() function is called * Apply my own passes that use the special MallocInst. This requires to recognize that some MallocInst are special MallocIns...

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,

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

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

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

Hi, I recently looked quite some time for why poolalloc wouldn't transform calls to malloc() in my program, until I noticed that it handles calls to malloc() (eg, stdlib pass) -- but only transforms MallocInst's. Is there a general policy on how passes should behave? Should they handle both representations, is doing -raiseallocs the preferred way, or do we explicitely not want any

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

Torvald, For what are you interested in poolalloc? I'm asking because we are trying to decide how to prioritize work on it. Thanks, --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org On Oct 27, 2007, at 11:10 AM, Torvald Riegel wrote: > Hi, > > I recently looked quite some time for why poolalloc wouldn't > transform calls > to malloc() in my program, until I

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 Vikram, I want to use poolalloc as a means for partitioning memory in Software Transactional Memory. We will have a paper about tuning parameters in word-based STMs in PPoPP 08, but there we use one configuration for the complete TM, which obviously has limitations in heterogenous workloads. Partitioning with poolalloc should give me (1) hopefully meaningful partitions (ie,

Daniel Waterworth skrev: > 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

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 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 all, 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 pretty much simpler as the getOperand(1) can give