similar to: [LLVMdev] Documentation of malloc/free

<please email llvmdev, not me directly> On Dec 7, 2009, at 8:47 AM, Florian Merz wrote: > Hi Chris, > > I do understand that you don't want to keep the whole history, but > to me > personally a simple line for recent changes like "introduced in 2.7" > or > "removed in 2.7" would have been nice, so this might be the case for > other >

Hi, The 20th of Novembre 2009, a LLVM BarCamp will be hold at La Cantine. Contributions, contributors, comments or any kind of help are welcome. Thanks and see you in Paris, Eric Mahe http://www.facebook.com/group.php?gid=140537112502 http://barcamp.org/LLVM-BarCamp-Paris -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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

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

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

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

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,

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.

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

Hey everyone, I'm currently trying to figure out a method for providing a unique identification of an llvm::Instruction that is consistent with the output of an AssemblyWriter. Obviously this is easy for named instructions: In this case the identification is the name itself, but I'd like to have the same thing for unnamed instructions. If I understand the code in AssemblyWriter.cpp

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

Chris Lattner wrote: > 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

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

Hi all! Writing a paper using a lot of boxplots I was asked to mark the significant differences between plotted groups using "stars on top". These stars are found freqeuntly in medical papers and printed above boxplots when there is a significant difference (usually using a bar to indicate which groups are meant if there are more then two in a plot). I was able to calculate whatever