cmd/compile: explicit zeroing memory returned by newobject

[mdempsky]

Compiling this code at 249aca5:

package p

type x [256][]byte

//go:noinline
func (*x) m() {}

func f() {
        a := x{}
        a.m()
}

generates a call to newobject (to heap allocate a) followed by code to zero it out (e.g., the call to typedmemmove).

There's a couple related questions:

1. newobject returns zero'd memory, so why are we still generating explicit zeroing code? Replacing a := x{} with var a x eliminates the explicit zero'ing.
2. typedmemclr would be better for explicit zero'ing, and CL 34566 actually fixes this... except I'm not sure why. (Edit: @cherrymui pointed out why in the CL.)
3. Why is a being heap allocated anyway? Shouldn't escape analysis be able to identify that (*x).m's parameters don't escape? (Edit: This appears to be cmd/compile: argument escapes when it should not #18001.)

/cc @randall77 @cherrymui @josharian @aclements @dr2chase

[cherrymui]

It still uses statictmp probably because CL https://go-review.googlesource.com/c/35261/ doesn't cover array?

I'm working on the new write barrier insertion code for #17583 (almost ready). Along that line I have prepared some changes that will remove the explicit zeroing (given that it doesn't use statictmp).

For the escape analysis, probably related to #18001?

[mdempsky]

It still uses statictmp probably because CL https://go-review.googlesource.com/c/35261/ doesn't cover array?

That explains why we were using statictmp originally. I don't understand though why s/OASWB/OAS/ would cause us to stop using statictmp though, since it's still an array literal assignment.

[mdempsky]

For the escape analysis, probably related to #18001?

Yes, that seems to be the same bug.

[cherrymui]

That explains why we were using statictmp originally. I don't understand though why s/OASWB/OAS/ would cause us to stop using statictmp though, since it's still an array literal assignment.

I replied in your CL.

[gopherbot]

CL https://golang.org/cl/36836 mentions this issue.

[josharian]

@cherrymui is this fixed? If not, what remains to be done?

[cherrymui]

I believe this is fixed. Thanks.
Closing.