cmd/compile: loops prevent bounds checking elimination

[elichai]

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

$ go version
go1.14

Does this issue reproduce with the latest release?

Yes

What did you do?

If I do some copies between arrays with a loop like:

func Convert(a *[32]byte, b *[4]uint64) {
	for i := 0; i < 4; i++ {
		binary.LittleEndian.PutUint64(a[i*8:], b[i])
	}
}

it bounds check on each array on every iteration.

but if I unroll it, it can figure out that it will never go out of bounds and eliminate the checks:

func Convert(a *[32]byte, b *[4]uint64) {
		binary.LittleEndian.PutUint64(a[:], b[0])
		binary.LittleEndian.PutUint64(a[8:], b[1])
		binary.LittleEndian.PutUint64(a[16:], b[2])
		binary.LittleEndian.PutUint64(a[24:], b[3])
}

godbolt: https://godbolt.org/z/E3c5r4

This means that when implementing performance critical code (ie cryptography) I find myself unrolling loops of 8-16 because they end up on pprof which really sucks for readability

[randall77]

We don't propagate known ranges through multiplies at the moment. Shouldn't be too hard to do in prove.go.

[gopherbot]

Change https://golang.org/cl/248701 mentions this issue: cmd/compile: add support for Lsh64*64 and Mul64 to IsSliceInBounds

[gtank]

Another cryptography implementer chiming in! It would be great to see this improved, and ideally for operations other than multiplication as well. It would specifically allow me to improve the readability of my code without suffering a notable (~30% on one task, see gtank/blake2#2 (comment)) performance penalty for not unrolling the loop.

I've tried hard to keep that library pure Go, and this makes it more likely that in a production deployment I'd have to pull in assembly to achieve the throughput expected of the algorithm itself (cc @FiloSottile).

[gopherbot]

Change https://go.dev/cl/599256 mentions this issue: cmd/compile: propagate constant ranges through multiplies and shifts