[LLVMdev] interesting possible compiler bug
kparzysz at codeaurora.org
Mon Oct 15 15:12:15 PDT 2012
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.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
More information about the llvm-dev