As evidence that this is just a missed optimization, here is equivalent code using a new intermediate type:

type T struct {
	c *A
}

type A struct {
	x [10]int
}

func (t *T) resetC() {
	for i := range t.c.x {
		t.c.x[i] = 0
	}
}

This generates runtime.memclrNoHeapPointers. (And also provides a workaround.)

There is a simpler workaround for i := range *t.a {.

@renthraysk I am astonished that that works, and I wrote the original optimization. Now that you say it, I can imagine why, although it has to do with weird quirks in the guts of the compiler. Anyway, I still think this is worth fixing. :P

Yea, agreed. Actually thought I filed an issue for this, but seems just tweeted about it back in 2017, so my bad.

Subtle diff in
func f1(in *[96]byte) { for i := range in { in[i] = 0 } }
func f2(in *[96]byte) { for i := range *in { in[i] = 0 } }

Change https://go.dev/cl/403337 mentions this issue: cmd/compile: support pointers to arrays in arrayClear

The following generates slightly more efficient code for my computer.

func (t *T) resetC() {
	*t.a = [10]int{}
}

There's no runtime.memclrNoHeapPointers call at all. Instead the compiler seems to choose a suitable algorithm based on the size of the array. To me it seems like all of the loops above should compile to this.

It looks the memclr way is more efficient than the assignment way for small arrays.
Should the runtime internal unify the implementation for the two ways?