[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