similar to: [LLVMdev] MallocInst/CallInst bitcast,

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

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.

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,

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

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

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

Out of curiosity, I'm replacing the JIT with MCJIT on my compiler. As all "external" functions are provided by the language's FFI mechanism, it does MyExecutionEngine->DisableSymbolSearching(); MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator); which works fine with the JIT. However, MCJIT insists on resolving unknown symbols by searching them

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

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

Óscar Fuentes <ofv at wanadoo.es> writes: > Out of curiosity, I'm replacing the JIT with MCJIT on my compiler. As > all "external" functions are provided by the language's FFI mechanism, > it does > > MyExecutionEngine->DisableSymbolSearching(); > MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator); > > which works fine

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

Chris Lattner wrote: > On Dec 23, 2008, at 9:14 AM, Jon Harrop wrote: >> I discovered that LLVM's malloc only allows a 32-bit size argument, >> so you >> cannot use it to allocate huge blocks on 64-bit machines. So I >> considered >> replacing all of my uses of LLVM's malloc instruction with calls to >> the libc >> malloc function instead.

>> 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, there's no reason to. -Chris

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

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

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