cmd/compile: unnecessary bounds check

[mariecurried]

What did you do?

I compiled the following program to see its assembly code: https://godbolt.org/z/OcRvPE

What did you expect to see?

I expected the access to the slice to not be bounds checked

What did you see instead?

A bounds check was generated by the Go compiler

[bradfitz]

Please use the issue template.

You don't specify what version of Go, for one, or which compiler.

[bradfitz]

Oh, I see your link goes to a site where "gc (tip)" is selected. But it's faster for us if you put all the relevant information in the bug. And conventionally we share play.golang.org code snippets. But in this case you can just inline the code:

package test

func test(slc []byte, i uint) {
	if len(slc) >= 3 {
		_ = slc[i%3]
	}
}

/cc @randall77 @aclements

[mariecurried]

Sorry, @bradfitz. I just assumed that you were familiar with Godbolt and, as you found out, the version is displayed there. But I'll take note for future reference.

[randall77]

I think this would just involve adding a new case for unsigned remainder to the prove pass.

[josharian]

cc @rasky

[cuonglm]

@randall77 Where should I look at in the source to fix this?

I see the current behavior convert the Mod64u to a Sub64, so prove failed.

If I assigned i = <any non negative number> before if, prove success, as it sees Const64.

[randall77]

True, that makes it trickier. We'd either have to recognize the results of the div->mul lowering (generic.rules:1161), or push the div->mul lowering later. Both seem challenging.

[rasky]

Maybe we should split div reduction out of generic into its own pass that runs late. It sounds something that later passes aren't dependent upon, and it tends to make code harder to analyze for everybody.

[josharian]

cc also @zdjones