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
marigonzes opened this Issue Jan 23, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@marigonzes
Copy link

marigonzes commented Jan 23, 2019

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

This comment has been minimized.

Copy link
Contributor

randall77 commented Jan 23, 2019

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.

@randall77 randall77 closed this Jan 23, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment