For all trivial and zero frame-sized functions, we now require an explicit
NOFRAME annotation as the heuristic has changed. See go.dev/cl/466316.
Most of these functions do not *require* NOFRAME, but this change encodes
the existing behavior in order to avoid accidental bugs or regressions.
PiperOrigin-RevId: 513946210
Part of a series of changes that will end with prohibiting use of sync/atomic
(u)int32 functions. See cl/440484071 for more details.
PiperOrigin-RevId: 442673296
All atomic 64 bit ints are changed to atomicbitops.(Ui|I)nt64. A nogo checker
enforces that sync/atomic 64 bit functions are not called.
For reviewers: the interesting changes are in the atomicbitops and checkaligned
packages.
Why do this?
- It is very easy to accidentally use atomic values without sync/atomic funcs.
- We have checkatomics, but this is optional and is forgotten in several places.
- Using a type+checker to enforce this seems less error prone and simpler.
- We get NoCopy protection.
- Use of 64 bit atomics can break 32 bit builds. We have types to handle this
without any runtime cost, so we might as well use them.
PiperOrigin-RevId: 440473398
BP should be callee-save. It will be saved automatically if there is nonzero frame size.
$ go vet -framepointer ./pkg/atomicbitops
pkg/atomicbitops/atomicbitops_amd64.s:27:1: frame pointer is clobbered before saving
pkg/atomicbitops/atomicbitops_amd64.s:34:1: frame pointer is clobbered before saving
pkg/atomicbitops/atomicbitops_amd64.s:50:1: frame pointer is clobbered before saving
pkg/atomicbitops/atomicbitops_amd64.s:57:1: frame pointer is clobbered before saving
pkg/atomicbitops/atomicbitops_amd64.s:64:1: frame pointer is clobbered before saving
Signed-off-by: Koichi Shiraishi <[email protected]>
In the case of other signals (preemption), inject a normal bounce and
defer the signal until the vCPU has been returned from guest mode.
PiperOrigin-RevId: 303799678
- Redocument memory ordering from "no ordering" to "acquire-release". (No
functional change: both LOCK WHATEVER on x86, and LDAXR/STLXR loops on ARM64,
already have this property.)
- Remove IncUnlessZeroInt32 and DecUnlessOneInt32, which were only faster than
the equivalent loops using sync/atomic before the Go compiler inlined
non-unsafe.Pointer atomics many releases ago.
PiperOrigin-RevId: 295811743
