Mul looks to be constant time already.

Constant time operations are only useful for crypto and the extra slowness is undesirable in every other domain. Just saying...

This issue is only about the Go fallbacks when intrinsics are not available for the target architecture.
The intrinsics are already constant time.

If your architecture doesn't have intrinsics, your code will already be extra slow. The fix in that case is to implement the intrinsics.

The goal is to have fast and safe intrinsics, it's why these functions were added. In the meantime, I'd rather have slow fallbacks than unsafe ones, though.

Not every architecture has add with carry, for example. If by "intrinsics" you mean e.g. ADC then it may very well happen that a non-constant time "fallback" will be faster than constant time implementation. What I try to say is that promising constant time fallbacks creates pressure for native implementations which except for crypto is not desirable, IMO.

The branchless, constant-time versions of Add and Sub from Hacker's Delight were originally proposed, but it was faster to compute the sum normally, and check a condition to compute the carryOut and borrowOut.

I have the constant-time version here that I can send in as a CL:
https://github.com/smasher164/extprec/blob/master/extprec.go

@smasher164 please do, yeah.

Change https://golang.org/cl/170758 mentions this issue: math/bits: make Add and Sub constant time

Discussion on #31267 about whether to change these.

Also, if someone wants to double-check the math/bits Add64 benchmark, that would be helpful. If it is literally never executing the 'carryOut = true' case, then it's a bad benchmark. It should do a mix of operations.

Looks like this is now a duplicate of #31267.