-
Notifications
You must be signed in to change notification settings - Fork 290
wazevo(amd64): reserve dx when calling memmove to support go 1.24 #2378
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
Conversation
Signed-off-by: Anuraag Agrawal <[email protected]>
f571a5c
to
2f093ff
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -1918,6 +1918,9 @@ func (m *machine) lowerCall(si *ssa.Instruction) { | |||
for i := regalloc.RealReg(0); i < 16; i++ { | |||
m.insert(m.allocateInstr().asDefineUninitializedReg(regInfo.RealRegToVReg[xmm0+i])) | |||
} | |||
// Since Go 1.24 it may also use DX, which is not reserved for the function call's 3 args. | |||
// https://github.com/golang/go/blob/go1.24.0/src/runtime/memmove_amd64.s#L123 | |||
m.insert(m.allocateInstr().asDefineUninitializedReg(regInfo.RealRegToVReg[rdx])) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of uninitialized, but shouldn't we need to put the proper value on it? otherwise it seems to me it would behave unexpectedly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe looking at the memmove signature change see what's the expected value on rdx
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(this makes me feel like this might not be the amd64 only issue)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah ok no i get it
…tratelabs#2378) Signed-off-by: Anuraag Agrawal <[email protected]>
Pick up bug fix for tetratelabs/wazero#2378
Fixes #2375
Go 1.24 changed memmove implementation on amd64, which resulted in an extra register allocation. This makes sure to reserve it for memmove invocation. While this could be a regression on go 1.23, it seems not significant enough to have version-specific code for this especially since it will go out-of-date soon.
Originally, @mathetake had suggested vendoring in the working go 1.23's memmove implementation, which both fixes and ensures forward compatibility, but I couldn't let go of the 30% perf gain from the change. After this, someone may want to try vendoring 1.24's implementation (it's not trivial due to needing to read many cpu flags), for forward compatibility, but before it I would check whether it's worth using the direct call to save on host function call overhead if implemented with normal
copy
.golang/go@601ea46