Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Yet another simplification of Dragonbox #2984

Merged
merged 3 commits into from
Jul 14, 2022
+7 −26
Merged

Yet another simplification of Dragonbox #2984

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
a1d1596
Simplify Dragonbox implementation
jk-jeon Jul 12, 2022
60a7608
Remove some branches
jk-jeon Jul 12, 2022
9165557
Remove unused constants.
jk-jeon Jul 14, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 7 additions & 22 deletions include/fmt/format-inl.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1337,7 +1337,7 @@ template <typename T> decimal_fp<T> to_decimal(T x) noexcept {

if (r < deltai) {
// Exclude the right endpoint if necessary.
if (r == 0 && z_mul.is_integer && !include_right_endpoint) {
if (r == 0 && (z_mul.is_integer & !include_right_endpoint)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why switch to bitwise AND? Better codegen?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. With logical AND, it generates three test instructions and three conditional branches. With bitwise AND, it generates two test instructions and two conditional branches. I thought compilers are aware of how to optimize this when all the things are just booleans variables (thus no short-circuit is really involved), but apparently they don't bother doing so. I am not sure why...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess, compilers are not sure if all boolean variables involved are really just 0 or 1. Like, if one is 2 and another is 1, they are both true so && should give true, but & will give 0. It is wrong from the first place to use bool for things with more than two states, but maybe the current standard allows bool variables to hold nonsensical values without UB.

--ret_value.significand;
r = float_info<T>::big_divisor;
goto small_divisor_case_label;
Expand All @@ -1346,26 +1346,11 @@ template <typename T> decimal_fp<T> to_decimal(T x) noexcept {
goto small_divisor_case_label;
} else {
// r == deltai; compare fractional parts.
const carrier_uint two_fl = two_fc - 1;

if (!include_left_endpoint ||
exponent < float_info<T>::case_fc_pm_half_lower_threshold ||
exponent > float_info<T>::divisibility_check_by_5_threshold) {
// If the left endpoint is not included, the condition for
// success is z^(f) < delta^(f) (odd parity).
// Otherwise, the inequalities on exponent ensure that
// x is not an integer, so if z^(f) >= delta^(f) (even parity), we in fact
// have strict inequality.
if (!cache_accessor<T>::compute_mul_parity(two_fl, cache, beta).parity) {
goto small_divisor_case_label;
}
} else {
const typename cache_accessor<T>::compute_mul_parity_result x_mul =
cache_accessor<T>::compute_mul_parity(two_fl, cache, beta);
if (!x_mul.parity && !x_mul.is_integer) {
goto small_divisor_case_label;
}
}
const typename cache_accessor<T>::compute_mul_parity_result x_mul =
cache_accessor<T>::compute_mul_parity(two_fc - 1, cache, beta);

if (!(x_mul.parity | (x_mul.is_integer & include_left_endpoint)))
goto small_divisor_case_label;
}
ret_value.exponent = minus_k + float_info<T>::kappa + 1;

Expand Down Expand Up @@ -1404,7 +1389,7 @@ template <typename T> decimal_fp<T> to_decimal(T x) noexcept {
// or equivalently, when y is an integer.
if (y_mul.parity != approx_y_parity)
--ret_value.significand;
else if (y_mul.is_integer && ret_value.significand % 2 != 0)
else if (y_mul.is_integer & (ret_value.significand % 2 != 0))
--ret_value.significand;
return ret_value;
}
Expand Down
4 changes: 0 additions & 4 deletions include/fmt/format.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1276,8 +1276,6 @@ template <> struct float_info<float> {
static const int small_divisor = 10;
static const int min_k = -31;
static const int max_k = 46;
static const int divisibility_check_by_5_threshold = 39;
static const int case_fc_pm_half_lower_threshold = -1;
Comment on lines -1279 to -1280
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these be removed from float_info<double> as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha. Another careless mistake. Sorry about that, it's fixed now.

static const int shorter_interval_tie_lower_threshold = -35;
static const int shorter_interval_tie_upper_threshold = -35;
};
Expand All @@ -1290,8 +1288,6 @@ template <> struct float_info<double> {
static const int small_divisor = 100;
static const int min_k = -292;
static const int max_k = 326;
static const int divisibility_check_by_5_threshold = 86;
static const int case_fc_pm_half_lower_threshold = -2;
static const int shorter_interval_tie_lower_threshold = -77;
static const int shorter_interval_tie_upper_threshold = -77;
};
Expand Down