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: regression in 69a7c15 #14920

Closed
OneOfOne opened this issue Mar 22, 2016 · 3 comments
Closed

cmd/compile: regression in 69a7c15 #14920

OneOfOne opened this issue Mar 22, 2016 · 3 comments
Labels
FrozenDueToAge
Milestone
Go1.7

Comments

@OneOfOne
Copy link
Contributor

Please answer these questions before submitting your issue. Thanks!

  1. What version of Go are you using (go version)?
    go version devel +5cdb3d0 2016-03-22 20:35:53 +0000 linux/amd64
  2. What operating system and processor architecture are you using (go env)?
    Linux amd64
  3. What did you do?
go get -u github.com/OneOfOne/xxhash
go test -bench=XXChecksum64\$ -benchtime 3s -tags safe github.com/OneOfOne/xxhash
  1. What did you expect to see?
    BenchmarkXXChecksum64-32 20000000 291 ns/op
  2. What did you see instead?
    BenchmarkXXChecksum64-8 5000000 870 ns/op

I ran a bisect and the offending commit is 69a7c15.
@OneOfOne OneOfOne changed the title cmd/compile: regression in 69a7c152a72 cmd/compile: regression in 69a7c15 Mar 22, 2016
@OneOfOne OneOfOne mentioned this issue Mar 22, 2016
Closed
@randall77
Copy link
Contributor

This looks like 69a7c15 broke the combine-8-byte-loads-into-a-quadword-load optimization. That's what the slowdown is coming from. I'll see if I can figure out why.

@ianlancetaylor ianlancetaylor added this to the Go1.7 milestone Mar 22, 2016
@gopherbot
Copy link

CL https://golang.org/cl/21004 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/21005 mentions this issue.

gopherbot pushed a commit that referenced this issue Mar 23, 2016
@randall77
cmd/compile: MOVBload and MOVBQZXload are the same op
68e86e6 
No need to have both ops when they do the same thing.
Just declare MOVBload to zero extend and we can get rid
of MOVBQZXload.  Same for W and L.

Kind of a followon cleanup for https://go-review.googlesource.com/c/19506/
Should enable an easier fix for #14920

Change-Id: I7cfac909a8ba387f433a6ae75c050740ebb34d42
Reviewed-on: https://go-review.googlesource.com/21004
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@golang golang locked and limited conversation to collaborators Mar 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.7
Development

No branches or pull requests
4 participants
@OneOfOne @ianlancetaylor @randall77 @gopherbot