[LLVMdev] malloc vs malloc

Nick Lewycky nicholas at mxc.ca
Mon Jan 12 19:45:28 PST 2009


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 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.
> 
> isa<FreeInst>(X) can be replaced with:
> 
> bool isFree(Instruction *X) {
>    if (CallInst *CI = dyn_cast<CallInst>(X))
>      if (Function *F = CI->getCalledFunction())
>        if (F->isName("free") && F->hasExternalLinkage())

Surely you mean "llvm.free" or something, right? I don't think we want 
to start assigning meaning to otherwise arbitrary function names.

Nick

>          return true;
>    return false;
> }
> 
> There is no need to have an actual IR object for it.  posix_memalign,  
> calloc, valloc and others are all great reasons why we shouldn't have  
> a MallocInst either.
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 




More information about the llvm-dev mailing list