将正确舍入的数学函数投入生产：LLVM-libc 的实践
内容提要
LLVM-libc 的数学库采用模块化设计，实现正确舍入，保证跨平台、跨版本结果一致。它通过快速路径加128位整数回退，兼顾精度与性能，避免传统 libm 的不可复现问题。MSVC 已将其用于 constexpr 求值。
延伸解读
正确舍入如何解决浮点一致性难题
传统 libm 在不同平台或版本上可能返回不同结果，导致分布式系统、游戏物理模拟等出现难以调试的差异。LLVM-libc 通过保证所有标准舍入模式下的正确舍入，使输出位模式由数学唯一确定，从而免费获得稳定性和一致性。这意味着库作者可以自由优化算法而不改变输出，下游测试也不会因库更新而失效。
性能与精度的平衡：快速路径与128位回退
LLVM-libc 的数学函数首先使用快速多项式近似（70-106位精度），并通过 Ziv 舍入测试判断结果是否明确。超过99.99%的输入走快速路径，性能接近非正确舍入库。对于极少数难舍入输入，回退到固定、无分支的128位或256位整数例程，由于最坏情况精度已数学证明不超过128位，因此无需任意精度库或堆分配，延迟有界，避免了传统方案中高达数千倍的性能悬崖。
历史教训：为何传统正确舍入方案被弃用
早期如 IBM libultim 尝试正确舍入，但回退路径使用高达768位的任意精度计算，导致某些输入下性能下降约6000倍，最终被 glibc 移除。LLVM-libc 的成功得益于数学界对最坏情况输入的长期研究，以及现代硬件对128位整数运算和 FMA 的支持，使得正确舍入在生产环境中变得可行。
对开发者的实际影响与采用现状
MSVC 已在 /Zc:cmath 下使用 LLVM-libc 进行编译期求值和运行时执行，C++23 和 C++26 的 constexpr 数学也将受益。对于需要跨平台、跨版本结果一致性的项目，如分布式系统、游戏同步、图像处理黄金测试，LLVM-libc 提供了无需自定义数学库或冻结编译标志的解决方案。开发者可以关注 LLVM-libc 的进展并参与社区贡献。
Q&A
LLVM-libc 的数学库为什么能保证跨平台结果一致？
因为它对所有标准舍入模式都实现了正确舍入，使得每个输入对应的输出位模式在数学上唯一，因此在不同平台、不同版本间结果完全一致。
传统 libm 在不同平台或版本上结果不一致会导致哪些实际问题？
会导致指令级差异（不同 CPU 厂商的硬件实现不同）、破坏黄金测试（输出位变化使测试基线失效）、以及游戏物理模拟不同步等问题。
LLVM-libc 如何在不牺牲性能的前提下实现正确舍入？
它采用两阶段策略：快速路径用双-双精度多项式近似（70-106 位精度）并执行 Ziv 舍入测试，超过 99.99% 的输入直接返回；对于极少数困难输入，回退到固定、无分支的 128 位或 256 位整数例程，无需任意精度库或堆分配，延迟有界。
什么是 Table-Maker's Dilemma，它为什么曾让正确舍入难以用于生产？
Table-Maker's Dilemma 是指：当近似值接近舍入边界时，需要多少额外中间精度才能保证舍入结果与精确数学值一致。早期因最大所需精度未知，回退路径使用高达 768 位的任意精度运算，导致性能骤降（如 pow 从约 70 周期增至 44 万周期），因此被认为不适合生产。
LLVM-libc 的数学库如何与 CORE-MATH、RLIBM 等项目合作？
LLVM-libc 数学团队与 CORE-MATH、RLIBM 积极合作，讨论算法方法、共享困难舍入测试向量、开发并行实现并交叉验证，从而确保正确性、优化性能并证明正确舍入可用于生产。
MSVC 在哪些场景下使用了 LLVM-libc 的数学函数？
当启用 /Zc:cmath 时，MSVC 将 LLVM-libc 用于数学函数的编译期求值（constexpr）和运行时执行。
