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

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

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

marigonzes opened this issue Sep 30, 2019 · 6 comments

Comments

@marigonzes
Copy link

@marigonzes marigonzes commented Sep 30, 2019

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

This comment has been minimized.

Copy link
Member

@andybons andybons commented Sep 30, 2019

@andybons andybons added this to the Unplanned milestone Sep 30, 2019
@randall77

This comment has been minimized.

Copy link
Contributor

@randall77 randall77 commented Sep 30, 2019

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

This comment has been minimized.

Copy link
Contributor

@josharian josharian commented Oct 1, 2019

@mvdan

This comment has been minimized.

Copy link
Member

@mvdan mvdan commented Oct 1, 2019

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

@josharian

This comment has been minimized.

Copy link
Contributor

@josharian josharian commented Oct 1, 2019

Sorry. I suspect it is a duplicate.

@randall77

This comment has been minimized.

Copy link
Contributor

@randall77 randall77 commented Oct 1, 2019

I concur.

@randall77 randall77 closed this Oct 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.