cmd/compile: Array/slice clearing idiom inconsistently recognized

[greatroar]

What version of Go are you using (go version)?

$ gotip version
go version devel go1.20-b1678e508b Wed Nov 16 04:04:52 2022 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What did you do?

package p

const N = 1 << 22

type T struct{ a, b int32 }

func arrayclear1(p *[N]T) { *p = [N]T{} }

func arrayclear2(p *[N]T) {
	for i := range p {
		p[i] = T{}
	}
}

func arrayclear3(p *[N]T) {
	for i := range p[:] {
		p[i] = T{}
	}
}

What did you expect to see?

Same code generated for all three.

What did you see instead?

arrayclear1 becomes REP STOSQ on amd64, REP STOSL on 386, a loop doing STP from ZR on arm64 and a simple loop on arm.

arrayclear2 becomes a call to runtime.memclrNoHeapPointers.

arrayclear3, which represents a library function that I found to be a hot spot, becomes a loop that sets one element at a time. On 386 and arm, that loop even includes a bounds check.

I suspected this might have to do with conversion to slice, but slice clearing is similarly inconsistent, producing different code depending on whether [:] (or [:n]) is present or not.

[randall77]

arrayclear2 calls into the runtime because the clearing detection doesn't have a special case for constant bounds like those that occur when iterating over pointer-to-arrays.
arrayclear3 doesn't detect that this is a clearing situation because it doesn't understand the relationship between p[:] (a slice) and p[i] (an index into a pointer-to-array). In fact, this is also why the bounds checks remain.
It should work to do

func arrayclear3(p *[N]T) {
	s := p[:]
	for i := range s {
		s[i] = T{}
	}
}

It's not clear to me that any of these are particularly important. Certainly it is easy to work around if you notice it.

It's not clear to me that 1 is faster than 2. I think it is on some more recent machines, but that's not why we chose it - sometimes we do memclrs in situations where calls are not allowed, so things like REP STOSQ or explicit loops are our only choice. The runtime call uses SSE/AVX/... which can be faster, especially for large memory regions.

I suspected this might have to do with conversion to slice, but slice clearing is similarly inconsistent, producing different code depending on whether [:] (or [:n]) is present or not.

This can be subtle. For instance,

func arrayclear4(s []T, n int) {
	for i := range s[:n] {
		s[i] = T{}
	}
}

We can't rewrite to a clear of some sort, because if len(s)<n<=cap(s), then this code should bounds-check panic when i reaches len(s).

[greatroar]

It's not clear to me that 1 is faster than 2.

My benchmarks suggest that they're about equally fast, on an Intel with the ERMS feature.

I'll patch that code, feel free to close if you deem this too unimportant.