[LLVMdev] interesting possible compiler bug

[Krzysztof Parzyszek]

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