-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: load after writebarrier call instead of spilling #15845
Comments
@cherrymui you might be interested in this. :) |
/cc @RLH @aclements |
@josharian, could you give an example of what the code would look like before and after with this change? |
I'm not sure what kind of answer would be helpful here. The goal is to replace |
That's actually exactly the kind of answer I was looking for. Thanks. Is the goal here just to reduce the needed spill space? It's not at all obvious to me that the new memory access pattern would be better. This obviously has weird effects if the program has races, but maybe we're okay with that. Alternatively, since we're passing src to the write barrier, should we just have the write barrier return src? (Or if the write barrier promises not to write to its argument, it can be reloaded straight from the argument slot, if that's not too scary. :) Even more alternatively, @RLH and I have talked a bit about using an SSB-style write barrier, mostly to improve register utilization around write barriers. This would have a very short fast path that just added the pointer to a per-P buffer (with a slow path to handle when this buffer overflows). The fast path could be coded in assembly to guarantee that it only uses some small set of registers, so the compiler could keep the rest across the write barrier call. The slow path would probably just save all registers; the type information doesn't matter here because it wouldn't be preemptible anyway. |
This sounds good to me--at least worth trying out.
This also sounds promising. |
This happened, and it's great. |
The inplace append optimization (CLs 21813 and 22197) use a trick to avoid a spill: When doing
*dst = src
via a write barrier, immediately dosrc = *dst
. (Search for a comment like "load the value we just stored to avoid having to spill it" in ssa.go.)If
src
is used again, it doesn't need to be spilled before the write barrier; it is a load either way, but we can skip the spill/store. Ifsrc
isn't used again, the load will be eliminated as dead code.Perhaps should we investigate extending this trick to all writebarrier-enabled pointer stores. Thoughts?
The text was updated successfully, but these errors were encountered: