[feature request] Is there any float arithmatic round support?

[LXYan2333]

Hello,

I wonder is there any round arithmetic support?

I'm writing a project, which needs to control the round direction of the float point arithmetic. for example:

// c++23
#include <bit>
#include <cfenv>
#include <cmath>
#include <cfenv>
#include <hwy/highway.h>
#include <immintrin.h>
#include <print>

namespace hn = hwy::HWY_NAMESPACE;

#pragma STDC FENV_ACCESS ON
#pragma STDC FENV_ROUND FE_DYNAMIC
#pragma GCC optimize "-frounding-math"
int main(void) {
  const hn::ScalableTag<double> d;
  auto x = hn::Set(d, std::bit_cast<double>(0b1ULL));
  auto y = hn::Set(d, 1.5);
  auto z = hn::Zero(d);

  std::println("normal fma: {} {}", fma(std::bit_cast<double>(0b1ULL), 1.5, 0),
               hn::GetLane(hn::MulAdd(x, y, z)));

  fesetround(FE_DOWNWARD);
  std::println("FE_DOWNWARD fma: {} {}",
               fma(std::bit_cast<double>(0b1ULL), 1.5, 0),
               hn::GetLane(hn::MulAdd(x, y, z)));

  fesetround(FE_UPWARD);
  std::println("FE_UPWARD fma: {} {}",
               fma(std::bit_cast<double>(0b1ULL), 1.5, 0),
               hn::GetLane(hn::MulAdd(x, y, z)));
}
#pragma GCC reset_options

compile with gcc 14.2.0, in Debug build, it output:

normal fma: 1e-323 1e-323
FE_DOWNWARD fma: 5e-324 5e-324
FE_UPWARD fma: 1e-323 1e-323

but in release build, it output

normal fma: 1e-323 1e-323
FE_DOWNWARD fma: 1e-323 1e-323
FE_UPWARD fma: 1e-323 1e-323

the <cmath>'s fma output wrong result, seems like a gcc's bug, but there is also no way to control round direction using Highway. I wonder whether is it possible, since there is intrinsic like _mm512_fmadd_round_pd to do fma with round.

[LXYan2333]

Seems very hard, the round varient FMA intrinsic only exists in avx512

[jan-wassenberg]

Hi, FYI this is a tricky topic. IIRC clang requires a compiler flag before it will even heed requests to change the rounding mode.
Happily, I am aware of work towards rounding support, but it will likely be some time before it lands.

[johnplatts]

@jan-wassenberg and @LXYan2333 - Here is a snippet to an implementation of AddWithRoundingMode, SubWithRoundingMode, MulWithRoundingMode, and DivWithRoundingMode (this snippet requires C++20, but the implementations of the Google Highway vector ops in this snippet work in C++17 mode and can be modified to work in C++11/C++14 mode by replacing if constexpr with HWY_IF_CONSTEXPR):
https://godbolt.org/z/fG7nEcdPv

[jan-wassenberg]

Wow, very interesting! I've shared this with colleagues working in this area. Thank you :) It seems like this would be cheaper than temporarily changing the rounding mode (=dozens of cycles).