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: unnecessary sign-extensions when converting int's #34625

Closed
mariecurried opened this issue Sep 30, 2019 · 6 comments
Closed

cmd/compile: unnecessary sign-extensions when converting int's #34625

mariecurried opened this issue Sep 30, 2019 · 6 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Milestone
Unplanned

Comments

@mariecurried
Copy link

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

$ go version
go version devel +2c47caa Sat Sep 28 13:50:34 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What did you do?

I tested the behavior of the Go compiler when facing conversions from int to uint/int values of different sizes.

What did you expect to see?

I expected then to be compiled down to a single instruction in most cases (don't know if this assumption is correct).

What did you see instead?

Instead, they are compiled to two instructions.

Examples (not a complete list):

func f(x int8) int64 {
    return int64(x)
}
movblzx "".x+8(SP), AX
movbqsx AL, AX
movq    AX, "".~r1+16(SP)
func f(x int16) uint64 {
    return uint64(x)
}
movwlzx "".x+8(SP), AX
movwqsx AX, AX
movq    AX, "".~r1+16(SP)
@andybons
Copy link
Member

@aclements

@andybons andybons added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 30, 2019
@andybons andybons added this to the Unplanned milestone Sep 30, 2019
@randall77
Copy link
Contributor

Yes, this is a known problem with loading of argument values from the stack.
We do the right thing for loads from other places:

func f(x int8) int64 {
	return int64(x)
}
func g(p *int8) int64 {
	return int64(*p)
}

f has an extra extension operation, but g does not.

Instead of a generic Arg opcode, we would need lots of opcodes like ArgAsInt8. Possible, but ugly.

Or maybe there's another way to fix it?

@josharian
Copy link
Contributor

#15300

@mvdan
Copy link
Member

mvdan commented Oct 1, 2019

@josharian do you mean that this issue is a duplicate, or simply that they're related?

@josharian
Copy link
Contributor

Sorry. I suspect it is a duplicate.

@randall77
Copy link
Contributor

I concur.

@golang golang locked and limited conversation to collaborators Sep 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
6 participants
@josharian @andybons @mvdan @randall77 @gopherbot @mariecurried