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