llvm dev - Jan 2009 - [LLVMdev] malloc vs malloc

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. That got me wondering why LLVM even has its  
>> own
>> malloc intrinsic anyway...
>>
>> Am I correct in assuming that LLVM's malloc intrinsic exists so
that
>> some
>> optimization passes can rewrite it, e.g. replacing heap allocation  
>> with stack
>> allocation when no part of the allocated value escapes scope? So  
>> replacing
>> all of my uses of LLVM's malloc with libc's malloc might hamper
LLVM's
>> optimizations and degrade performance?
> 
> Hi Jon,
> 
> 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?

Nick
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

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

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

There still are reasons to have it; just grep around for FreeInst.   
Function
attributes are not yet sufficient to replace all of those yet.

And if the ailgnment attribute on MallocInst were implemented, perhaps
via posix_memalign or other target-specific mechanisms, then MallocInst
would also have a reason to be kept.

Dan