HappenLee commented on PR #67463:
URL: https://github.com/apache/doris/pull/67463#issuecomment-5536575582
[P2] Consider preserving the safe int64 fast path
The previous implementation handled the common finite range [-2^63, 2^63)
with a direct, well-defined conversion to int64_t and returned immediately. The
new implementation sends every value through bit_cast, exponent/significand
decoding, wide-integer construction, and a multi-limb shift.
The binary64 decoder is necessary for values outside the built-in integer
range, but it may add avoidable work for ordinary small values, where a
hardware floating-point-to-int64 conversion is sufficient. Could we retain a
fast path similar to:
```cpp
constexpr double int64_min = -0x1p63;
constexpr double int64_limit = 0x1p63;
if (rhs >= int64_min && rhs < int64_limit) {
self = static_cast<int64_t>(rhs);
return;
}
```
and use the IEEE-754 decoder only for the large-value fallback? This keeps
the fix focused on the range that previously triggered undefined behavior while
preserving the inexpensive common path. If removing the fast path is
intentional, a focused microbenchmark covering typical small
Float/Double-to-wide-integer conversions would help demonstrate that the change
is neutral.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
