Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: some unreasonable in BCE decision making for global slices #47736

Closed
go101 opened this issue Aug 17, 2021 · 2 comments
Closed

cmd/compile: some unreasonable in BCE decision making for global slices #47736

go101 opened this issue Aug 17, 2021 · 2 comments

Comments

@go101
Copy link

@go101 go101 commented Aug 17, 2021

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

$ go version
go version go1.17 linux/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

package main

var s = make([]int, 100)

func f() (r int) {
	for i := range s {
		r += s[i] // bound check eliminated
	}
	return r
}

func g() {
	for i := range s {
		s[i] = i // need bound check
	}
}

func main() {
}

What did you expect to see?

Both bound checks are eliminated or both not.

What did you see instead?

One is eliminated but the other is not.

@mknyszek
Copy link
Contributor

@mknyszek mknyszek commented Aug 17, 2021

Loading

@randall77
Copy link
Contributor

@randall77 randall77 commented Aug 17, 2021

I believe this is because there are no writes in f. All the loads of s get coalesced into a single load, so prove can tell that the slice you're ranging over is the same as the one you're indexing.
In g, there's a write, so the s inside the loop is reloaded every time. That s might have a different length, so a bounds check is needed.

I don't think this qualifies as a bug. Closing. Maybe there's something that could be done with g, like proving that the location written doesn't alias the s global, but we haven't gone there yet.

Loading

@randall77 randall77 closed this Aug 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants