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: LittleEndian.PutUint64 compiles differently on tip #29896

Closed
mariecurried opened this issue Jan 23, 2019 · 1 comment
Closed

cmd/compile: LittleEndian.PutUint64 compiles differently on tip #29896

mariecurried opened this issue Jan 23, 2019 · 1 comment

Comments

@mariecurried
Copy link

What did you do?

I compiled the following code on tip, which generated the assembly code below:

package test

import "encoding/binary"

func test(x uint64) (out [8]byte) {
	binary.LittleEndian.PutUint64(out[:], x)
	return out
}
movq    $0, "".out+16(SP)
xchgl   AX, AX
movq    "".x+8(SP), AX
movq    AX, "".out+16(SP)
ret

What did you expect to see?

I expected the XCHGL instruction to not be there, as I don't think it makes much sense.
In version 1.11, the assembly code looks like this:

movq    $0, "".out+16(SP)
movq    "".x+8(SP), AX
movq    AX, "".out+16(SP)
ret

What did you see instead?

Instead, the XCHGL instruction is present, as shown in the first assembly snippet

@randall77
Copy link
Contributor

That is an inline mark that is left behind when inlining. It is a nop (0x90) so it shouldn't affect run time much (see https://go-review.googlesource.com/c/go/+/158057 for why "nop" is spelled "xchgl AX,AX").
It is used to ensure proper backtraces. It isn't needed in this case, as there's no faulting instruction which could reveal the inlining. To clean some of these up is #29571 .

Closing as a dup of #29571.

@golang golang locked and limited conversation to collaborators Jan 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants