[LLVMdev] interesting possible compiler bug

[Eli Friedman]

On Mon, Oct 15, 2012 at 3:12 PM, Krzysztof Parzyszek
<kparzysz at codeaurora.org> wrote:
> 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.

The optimization which triggers here is essentially dead malloc
elimination; we can end up with IR which looks a lot like the original
example in non-trivial cases because sometimes we can eliminate all
accesses to a block of malloc'ed memory (via inlining/GVN/etc.).

-Eli