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.

Sign up for GitHub

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: s[i:] should be treated the same as s[i:len(s):len(s)] #15116

Closed
OneOfOne opened this issue Apr 4, 2016 · 4 comments
Closed

cmd/compile: s[i:] should be treated the same as s[i:len(s):len(s)] #15116

OneOfOne opened this issue Apr 4, 2016 · 4 comments
Labels
FrozenDueToAge Performance
Milestone
Unplanned

Comments

@OneOfOne
Copy link
Contributor

OneOfOne commented Apr 4, 2016

Please answer these questions before submitting your issue. Thanks!

  1. What version of Go are you using (go version)?
    go version devel +bc94282 2016-04-04 21:22:44 +0000 linux/amd64
  2. What operating system and processor architecture are you using (go env)?
  3. What did you do?
func a(i int, in []byte) []byte { return in[i:] }
func b(i int, in []byte) []byte { return in[i:len(in):len(in)] }
  1. What did you expect to see?
    Same assembly for both.
  2. What did you see instead?
    a is larger.
@bradfitz
Copy link
Contributor

bradfitz commented Apr 4, 2016

/cc @brtzsnr @randall77

@bradfitz bradfitz added this to the Unplanned milestone Apr 4, 2016
@mdempsky
Copy link
Member

mdempsky commented Apr 4, 2016

in[i:] is the same as in[i:len(in):cap(in)], not in[i:len(in):len(in)]. If I change b to actually be semantically equivalent to a, then they compile to the same number of instructions for me on linux/amd64.

@mdempsky mdempsky closed this as completed Apr 4, 2016
@OneOfOne
Copy link
Contributor Author

OneOfOne commented Apr 4, 2016

So no way to get the lower number of instructions (aka in[i:len(in):len(in)]) without using that hack?

@mdempsky
Copy link
Member

mdempsky commented Apr 4, 2016

Your bug report as originally stated is invalid: you're comparing two functions with different semantics, so it's unsurprising that the Go compiler compiles them into different instruction sequences.

If you can suggest a more efficient instruction sequence that the Go compiler could use to implement a without altering its semantics, that would be something we could consider.

@golang golang locked and limited conversation to collaborators Apr 5, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Performance
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@bradfitz @mdempsky @OneOfOne @gopherbot