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? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e
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. -Chris
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 >