Our implementation of Halide::round is subtly misleading: most C++ coders would expect it to behave like std::round (which rounds halfway cases away from zero, regardless of the current rounding mode), but we actually implement it via llvm::nearbyint (which rounds halfway cases according to the current rounding mode, if any). This is an ugly trap to fall into because the difference can vary by environment.
Obviously, we can't just change the existing behavior of Halide::round as that would break existing code, but we need (1) put a proper implementation of round in place by another name, and (2) think about if there's a way to deprecate / rename / etc Halide::round to make it less of a poison-tipped needle.
Our implementation of
Halide::roundis subtly misleading: most C++ coders would expect it to behave likestd::round(which rounds halfway cases away from zero, regardless of the current rounding mode), but we actually implement it viallvm::nearbyint(which rounds halfway cases according to the current rounding mode, if any). This is an ugly trap to fall into because the difference can vary by environment.Obviously, we can't just change the existing behavior of
Halide::roundas that would break existing code, but we need (1) put a proper implementation ofroundin place by another name, and (2) think about if there's a way to deprecate / rename / etcHalide::roundto make it less of a poison-tipped needle.