[llvm-dev] Avoiding alloca elision

[David Blaikie via llvm-dev]

On Sat, Jul 13, 2019 at 3:11 PM Jorg Brown via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Sat, Jul 13, 2019 at 12:40 PM Sanjoy Das via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Samuel,
>>
>> You can't expect alloca's to reliably lower to stack pointer
>> adjustments.  The semantics of alloca is more high level -- it give
>> you an abstract memory location that lives and dies with the function
>> frame, but there is no guarantee that it will actually "allocate"
>> memory from the stack frame.  The compiler may promote the memory to
>> registers or (theoretically speaking, we don't do this today) even
>> demote it to a heap allocation.
>>
>
> What?!?
>
> 1) If it gets demoted to a heap allocation, when does the memory ever get
> freed?  There is no "freea" call, after all.
> 2) What alloca documentation are you looking at, that allows for heap
> allocation?
>
> As far as I know, if the memory can't be stack-allocated, alloca() is just
> supposed to return NULL... though frankly, as far as I can tell alloca is a
> nonstandard extension that is implemented differently from one platform to
> the next.  For that matter, even variable-length arrays in C aren't
> guaranteed to work.  (C11 made them optional?)  And interestingly, Linux
> went to the trouble of removing them all (
> https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kills-The-VLA )
>

I think Sanjoy was maybe talking in terms of LLVM's alloca intrinsic,
rather than the C API. But in any case, the C API seems quite implementable
with dynamic memory allocation - the basic API being "The alloca() function
allocates size bytes of space in the stack frame of the caller.  This
temporary space is automatically freed when the function that called
alloca() returns to its caller. - yeah, an implementation could implement
that in terms of dynamic memory allocation automatically freed at the end
of the function call.

The fact that it says "in the stack frame of the caller" is perhaps fuzzy
enough - we already have things like split stacks - seems plausible we
could have dynamically allocated stack frames, or partially dynamically
allocated ones - at which point alloca using such a thing would fit the
definition.




> -- Jorg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190713/f8cf7149/attachment.html>