[clang] Add _MM_FROUND_TIES_TO_EVEN to avx512fintrin.h (PR #99691)
via cfe-commits
cfe-commits at lists.llvm.org
Sat Jul 20 12:49:42 PDT 2024
hpkfft wrote:
I understand that the details of floating point arithmetic are somewhat of a specialized area of computer science. I suggest that this obligates a greater duty to show care and diligence, and so I thank you for not dismissing my concerns as too trivial to be worth discussing.
Rounding is necessary when the infinitely precise mathematical result of a floating point computation is not representable as a floating point number in the specified format (e.g., single precision). Let's ignore directed rounding (`roundTowardPositive`, `roundTowardNegative`, and `roundTowardZero`) for this comment. Often the mathematical result is closer to one particular representable floating point number than it is to any other. Then, this result (the nearest floating point number) is returned as the result. However, it may happen that the infinitely precise mathematical result is exactly half-way between two representable values. This is a tie. In this case, the IEEE Std 754-2019 rounding attribute `roundTiesToEven` specifies that, of the two equidistant representable results, the result returned should have a bit pattern ending in 0.
Hardware correctly implements the IEEE rounding attribute `roundTiesToEven`, so it seems best not to innovate in naming the macro. I would suggest that the Intel SDM phrasing `Round to nearest (even)` is less than optimal. A reader might be forgiven for mistakenly thinking that hardware always rounds to an even result. In a macro definition, there is merit in brevity, but not so much in a developer manual. I suggest `Round to nearest with ties rounding to even`.
Note that some few instructions, e.g., `ROUNDPS`, do round to an integer, so the existing macro definition `_MM_FROUND_TO_NEAREST_INT` ought not be deprecated.
I have written to the GCC mailing list to inquire as to whether they will accept this additional macro definition.
Regards,
Paul
https://github.com/llvm/llvm-project/pull/99691
More information about the cfe-commits
mailing list