similar to: [LLVMdev] libc malloc vs. llvm::MallocInst

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

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

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,

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

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

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,

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

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

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

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

On Dec 7, 2009, at 2:13 AM, Florian Merz wrote: > 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

On Dec 7, 2009, at 8:45 AM, Garrison Venn wrote: > 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? :-) No, we only support stack allocation in LLVM IR now. :-) You can call out to normal malloc and free, just like any external function. -Chris > >

So I gather this means that malloc was removed from the IR because there are platforms that don't have non-stack allocation semantics? Garrison On Dec 7, 2009, at 12:21, Chris Lattner wrote: > > On Dec 7, 2009, at 8:45 AM, Garrison Venn wrote: > >> 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

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*

Duncan, Thanks for brining the Ada issue to my attention. On Sep 22, 2009, at 6:11 AM, Duncan Sands wrote: > Hi Victor, this code from the verifier broke the Ada front-end build: > > const Module* M = CI.getParent()->getParent()->getParent(); > Constant *MallocFunc = M->getFunction("malloc"); > > if (CI.getOperand(0) == MallocFunc) { > const

On Dec 7, 2009, at 9:49 AM, Garrison Venn wrote: > So I gather this means that malloc was removed from the IR because > there are platforms that don't have non-stack allocation semantics? No, it was removed because it wasn't necessary, and the malloc 'instruction' didn't support 64-bit targets. -Chris > > Garrison > > On Dec 7, 2009, at 12:21, Chris