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

Jump to bottom

cmd/compile: using unsafe.Pointer will affect BCE optimization #17904

Closed
go101 opened this issue Nov 13, 2016 · 3 comments
Closed

cmd/compile: using unsafe.Pointer will affect BCE optimization #17904

go101 opened this issue Nov 13, 2016 · 3 comments
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@go101
Copy link

go101 commented Nov 13, 2016 •
edited

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

go version go1.7.3 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GORACE=""
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build745042352=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

What did you do?

https://play.golang.org/p/NYFLIpw7fp

What did you expect to see?

BCE works for line 52.

What did you see instead?

BCE doesn't work for line 52.
@bradfitz
Copy link
Contributor

Please write complete bug reports and answer the questions.

Your "What did you do?" section is lacking. You must have done more than that to see whether BCE was working. What are you using to evaluate the compiler's decisions?

@bradfitz bradfitz changed the title Using unsafe.Pointer will affect BCE optimization cmd/compile: using unsafe.Pointer will affect BCE optimization Nov 13, 2016
@bradfitz bradfitz added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Nov 13, 2016
@randall77
Copy link
Contributor

The reason the bounds check is not eliminated is that you're taking the address of a and b. That turns a bunch of optimizations off that would otherwise apply. When you write b (b = b[:len(a)]), the compiler doesn't know that you're not also writing a (it could with better alias analysis, but that doesn't exist yet). So it doesn't know that the len(a) used in b = b[:len(a)] is the same len(a) as the one used in the range statement.

A better way to check for aliasing is if &a[0] == &b[0]. It doesn't use unsafe and it allows BCE to work.

I'm going to close this bug for now. There are no plans for alias analysis at the moment, and if/when we do get there this issue can be revisited.

@go101
Copy link
Author

go101 commented Nov 14, 2016 •
edited

glad to know it is intended.

@golang golang locked and limited conversation to collaborators Nov 14, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@bradfitz @randall77 @gopherbot @go101