Xadd is now an intrinsic on amd64, which will complicate matters.

On the other hand, the intrinsic makes it cheaper to add a wrapper that checks for under/overflow (though the throw would still prevent inlining of the wrapper.)

I don't think we'd need an explicit throw: with a cmov to a guaranteed-invalid address, we could capture the signal with the same SIGSEGV handler that we use today for nil-pointer dereferences.

(Or does dereferencing possibly-nil pointers today also prevent inlining?)

@bcmills cmov always faults when given an invalid address, even if the condition is not satisfied.

So it does. (#TIL!)

Still, why would the throw prevent inlining when panics in general do not? (And does mid-stack inlining improve the situation at all?)

Still, why would the throw prevent inlining when panics in general do not? (And does mid-stack inlining improve the situation at all?)

Both throw and explicit calls to panic do prevent inlining right now. It's only implicit panics (inserted by the compiler for things like bounds checks or triggered by signals) that don't inhibit inlining.

Mid-stack inlining will probably make this a non-concern. There's nothing special about throw/panic that inhibits inlining. The inliner just sees them as calls, so the caller is a non-leaf function.