cc @randall77

See also #13095.

#13095 sounds like we should not lower them but instead improve the inlining and load+stores. We could still consider cases were we have hardware opcodes that can replace these functions such as Sqrt as these can not directly be simplified from go code to the opcode.

When intrinsifying more things in the compiler, please do not base the decision on the (package name, symbol name) alone. If I copy/vendor/fork the stdlib elsewhere, the identical package "math" code elsewhere should be just as fast.

... unless the package is some "guts" package like runtime or reflect. But normal packages which are pure Go (or could be pure Go) should not be blessed by the compiler based on whether they live in std or golang.org/x/* or github.

@bradfitz agreed in principle, although it is worth noting that Sqrt currently violates that principle, and I don't see any reasonable way to make that practice agree with principle. Most of the math functions are not like Sqrt, though.

@bradfitz good point. As for copying code that is then not lowered to opcodes (because of name change) it might also be the case that it does not produce equal results for some float math.

Sadly math.sqrt already seems to violate what you said. But i guess we can at least move math.Sqrt from frontend as intrinsic to the backend for cleanup since removing its special treatment would otherwise cause a performance regression.

So for now i have a look at lowering sqrt as an intrinsic and leave the rest alone :) (unless other reasons and candidates surface to handle more math functions as opcodes directly). If needed for compiler or runtime performance we could always have internal function names and lower only those.

@bradfitz how do we get value out of that, and how does that value compare to improved performance (which has also yet to be measured)? The cases I know where people want to replace libraries wholesale do not usually also require exact performance compatibility; in my experience it's for debugging (have done it myself) and performance is not critical.

That said, it plausible that we could build some flow-graph pattern-matchers for the things we wish to substitute (have also done that myself).

Also, sin and cosine are not candidates for this unless their inputs are range-reduced, and they're also x87 FP, not "modern" Intel FP. Very large inputs merely set a flag and return their input unmodified, so sin(2-to-the-64) returns 2-to-the-64. Intel hardware transcendentals use a 68-bit approximation of Pi (66-bits, but the first two missing bits are zero, so 68) which means that sin(machinePi) (for 53-bit mantissa double) is incorrect in its 16th bit, or at least it was back in the x87. (I may have misremembered the number of bits, but the last hex digit is C and it is more than 64)

// use number[m:n] notation to indicate value with same exponent as number, mantissa zero
// except for bits m through n-1 inclusive, where they are equal to their corresponding bits in
// number.  The first bit of the mantissa has index zero.
hwPi = realPi - realpi[68:]
swPi = realPi - realPi[53:]

// mathematical result -- goal is it get correctly rounded 53 bits of this.
sin (swPi) = sin (realPi - realPi[53:]) = sin(realPi[53:]) approx= realPi[53:]

// machine result "sin" = machine sine, sin = mathematical sine
"sin" (swPi) = "sin" (realPi - realPi[53:]) = - sin (realPi - realPi[53:] - hwPi) =
   - sin (realPi - realPi[53:] - (realPi - realpi[68:])) = -sin(realpi[68:]-realPi[53:]) =
  sin(realpi[53:]-realPi[68:]) = sin(realpi[53:68]) approx = realpi[53:68]
// i.e. 15 bits, then zeroes, where the true answer would have its 16th bit set.

I know this well, because Java's hotspot compiler once replaced correct software sine with incorrect hardware sine after the test loop had been executed "enough". Moving the problematic case to the front of the iteration ran it through the software path, and the problem would disappear.

For max and min math.Max and maxsd have different semantics in NAN case (at least on AMD64).
For ceil and floor math package currently uses roundsd instruction(sse4) + cpuid check, while compiler is limited to sse2, so this may actually cause slowdown.

These break down into:

1. Functions that sound trivial but are actually complicated once you include the special cases they need to get right (Abs, Ceil, ...) or the complexity of the implementation (Cos, Sin, ...).
2. Functions that can be written in Go and inline or should inline fine (Copysign, Float32bits, IsInf, IsNaN, ...).
3. Functions that have trivial, correct, not-possible-to-write-in-Go assembly implementations (Sqrt).

Only category 3 is worth turning into an intrinsic, and then only when it is a demonstrated hotspot in a plausible real program. We waited for years until we found a real demonstration that the call overhead for Sqrt mattered, and then we added the intrinsic.

If any of category 2 shows up as a hotspot and isn't written in the best inlinable way, better to do that. The current Inf and NaN may be examples of that, but it would help to have a demonstration that the current performance is inadequate.

I'm going to close this issue because it is so broad, but please feel free to open new specific ones for Inf, NaN, or any of the other specific cases, provided there's a plausible path to optimization and a plausible need.