Local Variables

[serkm]

Allocate local variables directly on the stack, with a special stack frame

[b-studios]

Nitpick, we now try to use the convention Foo_pointer. So this will be stackPointer_pointer

[b-studios]

Great job! Do you have results on running benchmarks on this?

[serkm]

I ran benchmarks and this seems to be slower in most cases.
Probably because we write 3 additional pointers to the stack for each variable.
Maybe this could be mitigated by allocating the variable in the next frame to be pushed, by adding a special case for Var(..., PushFrame(...))

[b-studios]

Thanks for running the benchmarks. Your analysis makes perfect sense! I think there are several things that we could do:

• flatten multiple variables into one (that is, var (x, y) = (1, 2); ...)
• somehow put the erasers and sharers relative to the return address so that we only store that one (1 store instead of 3)
• dynamically detect your special case (and my first special case here) and flatten at runtime (way too complicated, I guess).

What "normal" people do is to push a stackframe for every function. The stackframe has a "shape" and we thus know how many locals there will be at most (that means, we only have one eraser / sharer per frame-shape).

Now in our LLVM backend we do not push every function frame, but only val frames for non-tail calls. However, we could still do the same and statically allocate local mutable variables for each val frame. This might:

a) lead to longer lifetimes for some mutable variables
b) confuse LLVM in performing optimizations

[phischu]

Could you rebase onto current master? I can not reproduce the bad benchmarks, we should discuss offline.

[b-studios]

LGTM :)

[b-studios]

Let's keep the optimizations discussed above in mind, but ignore them for now.