<div dir="ltr"><div dir="ltr">On Sat, Jul 13, 2019 at 12:40 PM Sanjoy Das via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Samuel,<br>
<br>
You can't expect alloca's to reliably lower to stack pointer<br>
adjustments.  The semantics of alloca is more high level -- it give<br>
you an abstract memory location that lives and dies with the function<br>
frame, but there is no guarantee that it will actually "allocate"<br>
memory from the stack frame.  The compiler may promote the memory to<br>
registers or (theoretically speaking, we don't do this today) even<br>
demote it to a heap allocation.<br></blockquote><div><br></div><div>What?!?</div><div><br></div><div>1) If it gets demoted to a heap allocation, when does the memory ever get freed?  There is no "freea" call, after all.</div><div>2) What alloca documentation are you looking at, that allows for heap allocation?</div><div><br></div><div>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 ( <a href="https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kills-The-VLA">https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kills-The-VLA</a> )</div><div><br></div><div>-- Jorg</div></div></div>