I work on Skia. I recently attempted to replace our hand-rolled implementation of std::isfinite with the standard library version, trusting that a modern compiler's implementation would be equally efficient.
In practice, this led to a significant, measurable regression in our path-rendering code in clang-cl builds (which mixes Microsoft's STL with the Clang compiler).
I believe the discrepancy comes from https://github.com/microsoft/STL/blob/main/stl/inc/cmath . There does not appear to be support for clang's __builtin_isfinite. Other Clang builtins are supported, however—there are special codepaths for __builtin_ceilf, __builtin_floorf, __builtin_copysignf, and others. However, isfinite has no Clang builtin support, and ends up calling into fpclassifyd for each value, which is extremely expensive relative to the handful of instructions that a native isfinite needs.
I've filed this with our LLVM team (buganizer) but they said they could not control it from their end.
I work on Skia. I recently attempted to replace our hand-rolled implementation of
std::isfinitewith the standard library version, trusting that a modern compiler's implementation would be equally efficient.In practice, this led to a significant, measurable regression in our path-rendering code in clang-cl builds (which mixes Microsoft's STL with the Clang compiler).
I believe the discrepancy comes from https://github.com/microsoft/STL/blob/main/stl/inc/cmath . There does not appear to be support for clang's
__builtin_isfinite. Other Clang builtins are supported, however—there are special codepaths for __builtin_ceilf, __builtin_floorf, __builtin_copysignf, and others. However, isfinite has no Clang builtin support, and ends up calling intofpclassifydfor each value, which is extremely expensive relative to the handful of instructions that a nativeisfiniteneeds.I've filed this with our LLVM team (buganizer) but they said they could not control it from their end.