On 10/15/2012 4:39 PM, Eli Friedman wrote:> > The system malloc isn't, but the compiler can change any given call to > malloc to call an implementation which is known to return a non-null > pointer.Do we do that in LLVM? That would be surprising... Optimizing calls to malloc (like memory pooling for example) is not a trivial thing to do, and it requires a fairly strong interprocedural analysis. The fact that this seems to happen with LLVM at -O2 looks more like a bug than a clever optimization. -K -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Mon, Oct 15, 2012 at 2:43 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:> On 10/15/2012 4:39 PM, Eli Friedman wrote: >> >> >> The system malloc isn't, but the compiler can change any given call to >> malloc to call an implementation which is known to return a non-null >> pointer. > > > Do we do that in LLVM? That would be surprising... Optimizing calls to > malloc (like memory pooling for example) is not a trivial thing to do, and > it requires a fairly strong interprocedural analysis.Why would it require that? If you can see that the malloc doesn't escape you can, in such simple cases, simply move the data from malloc memory into an alloca instead.> The fact that this > seems to happen with LLVM at -O2 looks more like a bug than a clever > optimization. > > > -K > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by > The Linux Foundation > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 10/15/2012 4:49 PM, David Blaikie wrote:> On Mon, Oct 15, 2012 at 2:43 PM, Krzysztof Parzyszek >> >> Do we do that in LLVM? That would be surprising... Optimizing calls to >> malloc (like memory pooling for example) is not a trivial thing to do, and >> it requires a fairly strong interprocedural analysis. > > Why would it require that? If you can see that the malloc doesn't > escape you can, in such simple cases, simply move the data from malloc > memory into an alloca instead.You're right about moving data from heap to stack, but I think it would be somewhat limited in its scope. The compiler should be careful doing such things anyways, since the user can set stack and heap memory limits independently, and have expectations as to where the memory will be allocated at run time. Another thing is that if malloc is called twice, and neither call returns null, then the two pointers returned are guaranteed to be different. If you replace the call to malloc with alloca, the alloca (i.e. stack allocation) still needs to run in a loop. Of course, this doesn't have to happen in this particular example, but an optimization targeting this case is quite pointless. -K -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation