Escape analysis in the Elisp context

[quasilyte]

Allocations affect Emacs Lisp performance significantly.

There is a trick that can optimize away some unnecessary allocations, provided:

1. We are exploiting single-threaded nature of Emacs Lisp.
2. We have escape analysis that does not break valid code and can detect safe cases for optimizations.

For the code below:

func f(i, a, b, c, d int) int {
	var xs [4]int{a, b, c, d}
	return xs[i]
}

Naive implementation would allocate [4]int as (vector a b c d) for each invocation.

For this particular case, it is clever to store [nil nil nil nil] in the constant vector and perform 4 aset upon xs initialization. xs never "leak" (escape) away, so no observable effects are changed.

Same scheme can be applied for local objects that do not escape.
Since "true" objects are represented with lists and vectors, they always involve allocations.

This mechanism is not perfect and should not be used for big objects (and arrays).
The exact performance implications are yet to be measured.

Should also handle optimizations outlined in Goism object layout model article.

[quasilyte]

This is very long-term, but potentially very important for performance.