gcWriteBarrier and wbBufFlush assume that not writing to an argument
variable is sufficient to not clobber the corresponding argument slot.
This assumption lets us simplify the write barrier assembly code,
speed up the flush path, and reduce the stack usage of the write
barrier.
But it is an assumption, so this CL documents it to make this clear.
Alternatively, we could separate the register spill slots from the
argument slots in the write barrier, but that loses the advantages
above. On the other hand, it's extremely unlikely that we'll change
the behavior of the compiler to start clobbering argument slots (if
anything, we'd probably change it to *not* clobber argument slots even
if you wrote to the arguments).
Fixes #25512.
Change-Id: Ib2cf29c0d90956ca02b997ef6e7fa56fc8044efe
Reviewed-on: https://go-review.googlesource.com/127815
Reviewed-by: Cherry Zhang <cherryyz@google.com>
// Note: Every possible return from this function must reset
// the buffer's next pointer to prevent buffer overflow.
+ // This *must not* modify its arguments because this
+ // function's argument slots do double duty in gcWriteBarrier
+ // as register spill slots. Currently, not modifying the
+ // arguments is sufficient to keep the spill slots unmodified
+ // (which seems unlikely to change since it costs little and
+ // helps with debugging).
+
if getg().m.dying > 0 {
// We're going down. Not much point in write barriers
// and this way we can allow write barriers in the