You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(The ldr r0, [sp, #28] is reloading a spill of the variable bucket.)
The beq 114 branch jumps forwards to a block that uses r0 and r3. I'd expect the values in those registers to be rematerialized in that block, rather than in the body of a loop. (They don't appear to be live on any other edges out of this loop.)
@randall77 I noticed that about 24 hours ago your CL https://go-review.googlesource.com/c/go/+/79018 and commit 48e207d was submitted, touching mapassign_fast*. I am just totally guessing a correlation/possible update,
but could you or @philhofer please check if this still some work to be done here? Thank you!
I don't think my recent CL would change this, all the modifications were outside the probe loop.
Looking at disasembly, I see big changes at tip from the assembly listed here. I think the bucket variable is no longer restored in the loop, but the key we're searching for is.
So there's still work to be done.
On 73912a1
If you disassemble
runtime.mapassign_fast32
on ARM, you'll find the following code generated for the bucket probing loop:(The
ldr r0, [sp, #28]
is reloading a spill of the variablebucket
.)The
beq 114
branch jumps forwards to a block that usesr0
andr3
. I'd expect the values in those registers to be rematerialized in that block, rather than in the body of a loop. (They don't appear to be live on any other edges out of this loop.)Found while investigating #19495
The text was updated successfully, but these errors were encountered: