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
Comment From: randall77
We don't propagate known ranges through multiplies at the moment. Shouldn't be too hard to do in prove.go.
Comment From: gopherbot
Change https://golang.org/cl/248701 mentions this issue: cmd/compile: add support for Lsh64*64 and Mul64 to IsSliceInBounds
Comment From: 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 https://github.com/gtank/blake2/pull/2#discussion_r548232683) 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).
Comment From: gopherbot
Change https://go.dev/cl/599256 mentions this issue: cmd/compile: propagate constant ranges through multiplies and shifts