cmd/compile: evaluate map initializers incrementally

[randall77]

func g() int
func f() map[int]int {
	return map[int]int{
		1: g(),
		2: g(),
		3: g(),
	}
}

The generated assembly does essentially:

    m = make(map[int]int)
    v1 = g()
    v2 = g()
    v3 = g()
    m[1] = v1
    m[2] = v2
    m[3] = v3

It would be better to evaluate the function g just before we need its result. So instead, do:

    m = make(map[int]int)
    v1 = g()
    m[1] = v1
    v2 = g()
    m[2] = v2
    v3 = g()
    m[3] = v3

It should be safe to do so, as when we're constructing m no one but the current stack frame has a reference to it, so g can't see the difference.

See #26546 for an instance where this matters.

[josharian]

Are there order-of-evaluation guarantees for map literals? If so, the difference might be observable if one of the calls to g() panics.

[cherrymui]

If g() panics, the map literal should be inaccessible. So I think it should be fine.

[randall77]

We do need to respect order of evaluation, so there are tricky cases like:

func f() map[int]int {
	return map[int]int{
		k1(): v1(),
		k2(): v2(),
		k3(): v3(),
	}
}

Spec says the eval order must be k1,v1,k2,v2,k3,v3. But that should work fine with incremental building.

[randall77]

Punting to 1.13, too late for anything major in 1.12.

[gopherbot]

Change https://golang.org/cl/174417 mentions this issue: cmd/compile: evaluate map initializers incrementally

[gopherbot]

Change https://golang.org/cl/174498 mentions this issue: cmd/compile: remove dynamic entry handling from sinit/maplit