llvm dev - Dec 2020 - alloca behavior in llvm IR

Hi, Tim,


Thanks. Here comes another question. Given the code below.
----------------------------------------------------------------------

void notdead(int *);

int foo(int size, char * data) {

  int a = size;

  for (int i = 0; i < size; ++i) {

     int array[size];  // dynamic alloca

     notdead(array);

     a += size;

  }

  return size;
}
-------------------------------------------------------------------------
"a" is allocated in the stack of "foo".  and in
"for" loop, "array" is dynamic allocated. new space for
"array" is added to
current stack. SP is ajusted. we don't know how much SP is adjusted. After
that, "a" is accessed.
How would the compiler compute the address of "a"?  Would the compiler
access "a" through the frame pointer?
if that's true, when will the frame pointer be set? And when is a frame
pointer is needed?




Best Regards,
Jerry













At 2020-12-09 18:16:47, "Tim Northover" <t.p.northover at
gmail.com> wrote:
>On Wed, 9 Dec 2020 at 02:43, 林政宗 via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> I saw the code fragment as above. Is it possible that alloca is not
static?
>> And what is the behavior when alloca is not static?
>> When alloca is not in the entry block, it is not static. How would it
behave?
>
>The compiler will modify sp in the middle of the function to allocate
>more memory on the stack. If your alloca is in a loop it might even do
>that repeatedly (@llvm.stacksave and @llvm.stackrestore can help
>here).
>
>> Would it adjust the stack for the current function?
>
>The memory would become part of the current function's stack frame,
>and still get freed when it returns.
>
>Cheers.
>
>Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201215/c5f205b1/attachment.html>

On Tue, 15 Dec 2020 at 02:45, 林政宗 <jackie_linzz at 126.com>
wrote:
> How would the compiler compute the address of "a"?  Would the
compiler access "a" through the frame pointer?
That's usually what happens, yes. Sometimes it may be yet another
pointer called a "base pointer" though (for example
https://godbolt.org/z/1z3WYM computes var's address from x19 because
the stack was realigned so the offset from the frame pointer is no
longer a compile-time constant).
> if that's true, when will the frame pointer be set?
It's generally set in prologue code emitted by XYZFrameLowering.cpp.
> And when is a frame pointer is needed?
That's not an easy question to answer I'm afraid. Some platforms
always require a frame pointer (to improve back-traces for example),
otherwise there's a whole host of odd edge-cases in what functions
need that add a frame pointer to the mix.

For example the function that makes the decision on AArch64 is here:
https://github.com/llvm/llvm-project/blob/9c328e7afafd15795fed54e3b0c1c5bd4fa97dfa/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp#L297

Cheers.

Tim.