Change `rint` to `roundeven` in `round_ties_even` implementation

[tgross35]

C has three reasonably similar ways to round a single float to even. I'll just copy the docs here, nearbyint:

Description

The nearbyint functions round their argument to an integer value in floating-point format, using the current rounding direction and without raising the "inexact" floating-point exception.

Returns

The nearbyint functions return the rounded integer value.

rint:

Description

The rint functions differ from the nearbyint functions (7.12.9.3) only in that the rint functions may raise the "inexact" floating-point exception if the result differs in value from the argument

Returns

The rint functions return the rounded integer value.

And roundeven, which is available since C23:

Description

The roundeven functions round their argument to the nearest integer value in floating-point format, rounding halfway cases to even (that is, to the nearest value that is an even integer), regardless of the current rounding direction

Returns

The round functions return the rounded integer value.

We currently use rintf16, rintf32, rintf64, and rintf128 (e.g. https://doc.rust-lang.org/std/intrinsics/fn.rintf32.html) as the intrinsics to implement round_ties_even. These map to LLVM's rint and similar:

rust/compiler/rustc_codegen_llvm/src/intrinsic.rs

Lines 129 to 132 in 613bdd4

	sym::rintf16 => "llvm.rint.f16",
	sym::rintf32 => "llvm.rint.f32",
	sym::rintf64 => "llvm.rint.f64",
	sym::rintf128 => "llvm.rint.f128",

rint is not exactly what we want here because it is supposed to raise inexact. We should change to roundeven because it matches Rust's preference of ignoring rounding modes and never raising fp exceptions.

This may be blocked on platform support, e.g. llvm/llvm-project#73588. that issue looks like it is about the vector version.

Cc #55107.

[tgross35]

I tested the below code on a handful of Tier1/2/3 targets with llc main and didn't run into any selection failures, so LLVM support seems fine. However, on many platforms this lowers to a libcall; since roundint is C23, it is probably safe to say that this isn't available in system libraries on many of our platforms. So I think I need to add this to libm before we make any changes here.

define noundef float @round_f32(float noundef %x) unnamed_addr {
start:
  %0 = tail call float @llvm.round.f32(float %x)
  ret float %0
}

define noundef float @rint_f32(float noundef %x) unnamed_addr {
start:
  %0 = tail call float @llvm.rint.f32(float %x)
  ret float %0
}

define noundef float @roundeven_f32(float noundef %x) unnamed_addr {
start:
  %0 = tail call float @llvm.roundeven.f32(float %x)
  ret float %0
}

define noundef double @round_f64(double noundef %x) unnamed_addr {
start:
  %0 = tail call double @llvm.round.f64(double %x)
  ret double %0
}

define noundef double @rint_f64(double noundef %x) unnamed_addr {
start:
  %0 = tail call double @llvm.rint.f64(double %x)
  ret double %0

}
define noundef double @roundeven_f64(double noundef %x) unnamed_addr {
start:
  %0 = tail call double @llvm.roundeven.f64(double %x)
  ret double %0
}

[hanna-kruppe]

rint is not exactly what we want here because it is supposed to raise inexact. We should change to roundeven because it matches Rust's preference of ignoring rounding modes and never raising fp exceptions.

Keep in mind that the C standard and related documents are written with FENV_ACCESS in mind, but LLVM’s normal (not “constrained”) intrinsics operate in what LLVM calls the default floating point environment, where rounding mode is always to nearest and exceptions are ignored, same as what Rust does. The lowering on most platforms still raises exceptions but that’s because it’s the most efficient lowering and the difference doesn’t matter for programs that adhere to the “default fenv” rules. So I don’t see any reason to change the lowering from Rust to LLVM IR.

[tgross35]

I should have clarified this but the impression I got from other threads is that roundeven is more amenable to optimization than rint. AIUI even though LLVM doesn't have fenv access, it is not allowed to autovectorize rint while it can for exception-free nearbyint https://llvm.org/docs/Vectorizers.html#vectorization-of-function-calls. I am assuming roundeven just hasn't made it onto that list yet because it is newer? (cc @nikic if you know any context). And per #55107 (comment), roundeven may have better hardware support, though I haven't dug into this.

[RalfJung]

FWIW, LLVM also has nearbyint intrinsics. Maybe we should use that?

As far as I can tell, the LLVM semantics of nearbyint, rint, and roundeven are entirely identical when used without "Constrained Floating-Point Intrinsics" metadata, since they all assume the default FP environment -- @nikic does that sound right? So it seems like an LLVM bug to me that they would get vectorized differently.

[hanna-kruppe]

See also llvm/llvm-project#77561

[nikic]

I should have clarified this but the impression I got from other threads is that roundeven is more amenable to optimization than rint. AIUI even though LLVM doesn't have fenv access, it is not allowed to autovectorize rint while it can for exception-free nearbyint https://llvm.org/docs/Vectorizers.html#vectorization-of-function-calls. I am assuming roundeven just hasn't made it onto that list yet because it is newer? (cc @nikic

I think that documentations is just outdated, in reality all three support vectorization: https://github.com/llvm/llvm-project/blob/76e73ae6af1cecffaf977391e52bb9c410c14ff1/llvm/lib/Analysis/VectorUtils.cpp#L94-L97

[tgross35]

FWIW, LLVM also has nearbyint intrinsics. Maybe we should use that?

That would also work. But since C23 is now out I feel as though we may as well just use roundeven, if for no other reason than it being the best representation of our intent. Polyfill in libm would be needed of course.