Rust and SPIR-V float rounding semantics are different

There is a footgun when trying to share code between CPU and GPU. Rust and SPIR-V have different semantics when rounding floats:

Rust:

• Rust’s built-in conversion using as truncates the fractional part, effectively rounding toward zero.
• For example, 1743028479.999... becomes 1743028479.
  Rust Language Reference

SPIR-V:

• SPIR-V uses the OpConvertFToS instruction for converting floating-point values to integers. Here is where it happens in rust-gpu.
• It rounds using round-to-nearest-even, which can round 1743028479.999... up to 1743028480.
  SPIR-V Specification

fn main() {
    let x = 1743028480i32;
    let y = (x as f64) * (1.0 / (i32::MAX as f64));

    // Without explicit rounding, differs:
    let without = (y * (i32::MAX as f64)) as i32;
    // Using `trunc()` forces Rust’s truncation:
    let with = (y * (i32::MAX as f64)).trunc() as i32;

    println!("x = {}. Without rounding = {}. With trunc() = {}.", x, without, with);
}

I'm not sure which should be the default. If it is Rust's we'll want to polyfill on the spir-v side. Might be good to have this user controlled in any case.

Originally posted by @LegNeato in https://github.com/Rust-GPU/rust-gpu/discussions/228#discussioncomment-12784276

Start at crates/rustc_codegen_spirv/src/builder/builder_methods.rs around the referenced OpConvertFToS generation, then compare the Rust reference and SPIR-V specification linked in the issue. Determine the intended default or user-controlled behavior for float-to-integer conversion and validate it against the provided example. Done means the chosen semantics are explicitly agreed and the CPU/GPU behavior is aligned or deliberately configurable.