Add own version of the mathematical constants from the upcoming C++20 `std::numbers`.

# Details

# Diff Detail

- Repository
- rG LLVM Github Monorepo

### Event Timeline

llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp | ||
---|---|---|

5003 | I don't like taking a 64-bit constant and truncating it to 32 bits. For most common mathematical constants, it probably produces the right result, but it's not correctly rounded in general. | |

llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp | ||

1943–1944 | Do we actually have enough precision here if the type is long double? |

llvm/include/llvm/Support/MathExtras.h | ||
---|---|---|

69 | Please use the correct number of digits (the smallest number of digits required to produce the correct double-precision result). Adding extra digits which don't actually affect the value is confusing. |

llvm/include/llvm/Support/MathExtras.h | ||
---|---|---|

66 | The correct value of sqrt(2) in double-precision is 1.4142135623730951. And now I don't trust any of the other values... | |

71 | Please mark the constants with "f", e.g. | |

llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp | ||

1944 | I'm not sure this describes the issue correctly. You can specify a long double as a string, or raw bits. It can't interoperate with the native long double because that might have the wrong width. |

llvm/include/llvm/Support/MathExtras.h | ||
---|---|---|

66 |
Besides, the reference I provided states that this value is 1.41421356237309505. Whether it's rounded to 1.4142135623730950 or 1.4142135623730951 is a bit moot, IMO. | |

llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp | ||

1944 | What wording would you suggest, please? |

llvm/include/llvm/Support/MathExtras.h | ||
---|---|---|

66 | I asked for "the smallest number of digits required to produce the correct double-precision result". This is what you get if, for example, you ask Python 2.7 or later to convert the value to a string with Yes, a one ulp difference is unlikely to matter for most uses, but if we're going to take the time to define these, we should define them correctly. | |

llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp | ||

1944 | Maybe just |

llvm/include/llvm/Support/MathExtras.h | ||
---|---|---|

66 | You're assuming that Python is correct. As I said, the precision of |

@efriedma, you had a point. I now trimmed the precision down to one digit short of seeing a change in the mantissa bits.

LGTM

llvm/include/llvm/Support/MathExtras.h | ||
---|---|---|

66 | 1.4142135623730951 is the shortest decimal representation that produces the same double-precision number as 0x1.6a09e667f3bcdP+0. It isn't "correct" in any other sense, sure. A few extra digits is okay, I guess. |

llvm/include/llvm/Support/MathExtras.h | ||
---|---|---|

66 | Indeed, for some numbers more digits were necessary than for others. For uniformity's sake, I used the maximum from the number of digits required. Thank you. |