runtime: de-duplicate bit operations with math/bits

[aclements]

For the page allocator rewrite, @mknyszek tried to depend on math/bits in the runtime. This almost works, but conflicts with go test -coverpkg=all (#35461) because that tries to instrument math/bits in ways that are incompatible with running inside the runtime. In order to get this working, CL 206199 duplicated some math/bits functions into the runtime (and CL 206200 intrinsified them).

This duplication was expedient, but unfortunate, and for 1.15 I'd like to reconsider this. A few possibilities:

1. -coverpkg=all shouldn't apply to anything the runtime depends on. You'd hardly be losing anything if it didn't cover math/bits since almost all of those functions are intrinsified anyway.

2. If the cover tool can switch to using compiler-inserted coverage information, rather than source rewriting, it's possible this problem will go away.

/cc @dr2chase @cherrymui @mdempsky

[cherrymui]

If the cover tool can switch to using compiler-inserted coverage information, rather than source rewriting, it's possible this problem will go away.

The failure only happens when both -coverpkg=all and the race detector are enabled. The cover tool inserts a call to sync/atomic.AddUint32 (or like), which is further instrumented by the race detector, making it a call to the race detector code, when it doesn't have a P (e.g. in schedinit).

It might work fine if it is just an atomic counter increment.

[mdempsky]

Unifying with fuzzing instrumentation sounds good to me, and would avoid the dependency loop. I can play around with this during the freeze.

[odeke-em]

Howdy Austin, Cherry and Matthew? I shall move this to Go1.16, but please feel free to adjust it as you please.

[aclements]

Thanks @odeke-em . @mdempsky, just curious if you had any opportunity to look at unifying the fuzzing instrumentation.

[mdempsky]

@aclements No, not yet.

[ianlancetaylor]

Moving to Backlog.