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 subsequent bounds checks are not eliminated #50365

Open
tdakkota opened this issue Dec 27, 2021 · 3 comments
Open

cmd/compile: some subsequent bounds checks are not eliminated #50365

tdakkota opened this issue Dec 27, 2021 · 3 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Milestone

Comments

@tdakkota
Copy link

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

$ go version
go version devel go1.18-088bb4b Tue Nov 2 06:25:39 2021 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env

What did you do?

https://go.dev/play/p/eyem-XNTdye
https://go.godbolt.org/z/bMTGW9E7W

What did you expect to see?

Since i and size are always positive numbers,

i*size+1 is not equal to zero and will be always greater than i*size, so

data[i*size]

check can be eliminated.

If i*size+1 overflows or i*size+1 >= len(data), data[i*size+1] will panic before accessing data[i*size].

What did you see instead?

Compiler emits two checks.

@tdakkota tdakkota changed the title cmd/compile: some subsequent bound checks are not eliminated cmd/compile: some subsequent bounds checks are not eliminated Dec 27, 2021
@randall77
Copy link
Contributor

Since i and size are always positive numbers,

isize+1 is not equal to zero and will be always greater than isize, so

data[i*size]
check can be eliminated.

That's not always true. For instance in int8 space, 5*51+1 == 0, but 5*51 == -1. I think the size==2 case is safe, but probably most sizes (including 5) aren't. The numbers are larger for int32 and int64 but the same situation happens.

@tdakkota
Copy link
Author

Isn't it true for all even non-zero size (size > 0 && size % 2 == 0)?

@randall77
Copy link
Contributor

Yes, I think all size%2==0 are ok, with i*size+1 at least.

@seankhliao seankhliao added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance labels Jan 16, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
@seankhliao seankhliao added this to the Unplanned milestone Aug 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Projects
Status: Triage Backlog
Development

No branches or pull requests

4 participants